It would be cool in the future to build a language server for makefiles. The main problem is that the language of makefiles is a context-sensitive grammar. There is no way AFAIK to write a context-free grammar (e.g., BNF for makefiles is impossible). A simple example is how .RECIPEPREFIX is a variable that must be evaluated in order to lex/parse the grammar.
However, during our context-sensitive parsing, we could theoretically have an intermediate form that is more general (currently we throw vars into the Vars struct and rules into the RuleMap struct. We could, in parallel with that process, populate a pseudo-syntax-tree, which would probably take the form of an array where each element represents a line and metadata about what that line is. Then, rules/vars could store references/indices to that for storage of the context for logging purposes. This would cut down on memory consumption. The alternative is to do these two things in parallel and continue to store context in the rules or temporarily during parsing, and only enable this pseudo-syntax-tree when specifically requested, and probably only in the context of a language server or some other meta-tool.
It would be cool in the future to build a language server for makefiles. The main problem is that the language of makefiles is a context-sensitive grammar. There is no way AFAIK to write a context-free grammar (e.g., BNF for makefiles is impossible). A simple example is how
.RECIPEPREFIX
is a variable that must be evaluated in order to lex/parse the grammar.However, during our context-sensitive parsing, we could theoretically have an intermediate form that is more general (currently we throw vars into the
Vars
struct and rules into theRuleMap
struct. We could, in parallel with that process, populate a pseudo-syntax-tree, which would probably take the form of an array where each element represents a line and metadata about what that line is. Then, rules/vars could store references/indices to that for storage of the context for logging purposes. This would cut down on memory consumption. The alternative is to do these two things in parallel and continue to store context in the rules or temporarily during parsing, and only enable this pseudo-syntax-tree when specifically requested, and probably only in the context of a language server or some other meta-tool.