Determining all including files is incomplete

[nittka]

LilyPondBuilder#allIncludingFiles is used to determine all files that depend on a given file F. If F changes all the (directly and indirectly) including ones may be affected.

The current implementation uses project references in order to find possibly affected files. However, LilyPond does not use eclipse mechanisms and includes are based on absolute location only. Hence, there may be a dependencies not reflected by project references.

What could be done:

• automatically add project references if an include is detected
• always scan the entire workspace
• use the index to extract the dependencies
• other ideas?

One thing that also bothers me about the current implementation is that the entire parsing and linking is done once more (LilyPondBuilder#getIncludedFiles) potentially for many, many files and implicit includes via search path may not be considered at all.

My feeling is that the index information should be used...

[thSoft]

Yes, this is a known limitation that would be great to overcome. I vote for the index, it is the conventional storage for this kind of information.

[nittka]

The idea of the first commit (branch https://github.com/nittka/elysium/tree/includingByIndex) is to use the include information already determined by LilyPondImportUriGlobalScopeProvider#getImportedUris. Storing the information in the index user data is not "trivial" because it is calculated before linking. Rather than doing the import resolution twice, the transitive includes are stored as ReferenceDescriptions (not EObject to EObject, but resource to resource). Only the explicit includes are stored, as default includes should not be affected (the information is to be used for recompile and refactorings, but the default includes should not be involved in these operations).

During linking the includes are stored in the resource's cache and extracted from there during index creation. The LilyPond builder can then access the index information to retrieve the includes.

In the long run it might be interesting to separate direct includes from all includes (refactoring operations).

[nittka]

Index information is used to determine which files need recompilation. The logic needed for refactorings may require further changes and will be dealt with in the corresponding ticket.