gregschmit / omake Goto Github PK

-i or --ignore-errors.

The RuleMap should not store .IGNORE normally, otherwise it would be blank by default which would indicate ignore errors for all targets. Rather, we should include a special field ignore on the struct that should be somehow be falsy by default, truthy if -i is given or .IGNORE is set with no value, or a list of strings representing the targets to ignore. Maybe Option<Vec<String>>, where None is default, empty array means ignore for all targets, and a list of targets otherwise.

Separately, - command prefix should ignore errors for that line no matter what.

Ultimately, I want to support all BSD and GNU variants. BSD variants all seem to start with a period (e.g., .if, .for), so that means there shouldn't be any conflicts.

We can't get around this with a preprocessor because the conditionals and loops will depend on variable state, so this needs to be baked into the normal parser. This can probably be done similar to how variable expansion is done: by having vector of Frame structs which will behave as a stack and when we come across control flow statements, we just need to push to or pop from the stack, and when popping, evaluate the inner portion properly (for conditionals we just decide to parse the inner or not, and with loops we execute the inner however many times we need, resetting the line number state and handling the variable assignments properly).

The only thing that concerns me is nested control flow, where we almost have to evaluate temporarily because there could be a wrapping conditional that ignores everything, or a wrapping for that iterates everything.

So this is probably going to be a headache.

I see a possible need for this to allow us to easily switch between gnu and bsd make modes, by i.e:
--make-mode=bsd or --make-mode=gnu .

And for any improvements we make that might cause issues in edge cases:
--omake-fallback=list,of,features where any feature passed here could fallback to an impl that more closely translates make 1:1.

This is just an idea.

Some command line options aren't used at all because Makefile has no visibility of the clap arguments. I don't want the lib crate to depend on clap, so an Args struct needs to be written inside the lib and the bin must map the clap-parsed args to this plain struct.

Should also consider figuring out which args need to be passed to sub-make and getting the special variable MAKE figured out.

My suggestion is to create a github project to track progress on features and group issues under them, this should help anyone wishing to contribute pick a starting point.

Regards

Hi,

My interest in omake comes from an obsession with POSIX compliant. In short, I would like to validate my makefile's similarly to make -n, but using a command that won't accidentally permit extensions to the POSIX make standard.

For example, make -n will let GNU-isms slip through unnoticed, if the user has GNU make installed.

Can we get a command line flag for omake to disable GNU-like extensions to the POSIX make standard?

Does omake support the full POSIX make AST?

Hi,

I like the idea of using Rust to safely parse makefiles. Can we please get a Rust API published for omake?

That way, we can parse and navigate makefile structures with downstream Rust projects!

We need a mechanism so special targets can capture the list of prerequisites and store them in an easily retrievable way. They should probably be stored on the Makefile struct as Vec<String>. Two good examples to implement: .PHONY and .IGNORE

In my excitement of learning common patterns in Rust, I might have over-engineered this project. Currently it is separated into a lib crate and a bin crate, the idea being to separate concerns of core logic and frontend, and also so certain logic could be reused if another project wanted to, for example, make a different frontend to omake.

The problem I'm seeing is that I had to separate Args and Opts struct so the lib would not depend on clap, and this requires manual duplication of a handful of struct fields that must be kept in sync. Furthermore, sub-MAKE (related to #8) would need to know the command line options to execute and would need to know how the parent process was invoked, so it seems like a lot of the backend logic is tightly coupled to the binary aspect of this project.

I'm considering removing the lib crate and just making this project a single bin crate.

Thoughts?

@neonimp

The Makefile struct should have a logger field, which is something that implements MakeLogger trait, which implements info, warn, and error methods for logging. The default implementation will be to print to stdout/stderr.

This will help future efforts to make a re-usable library (that can also be used for a language server).

We should add MAKE as a special key for the Vars struct (much like .RECIPEPREFIX and set it to however the current program was invoked.

Implement with flag -n, and long flags --just-print, --dry-run, and --recon.

Print recipe lines but don't execute unless lines start with command prefix + or contain sub-make calls.

Reference: https://www.gnu.org/software/make/manual/html_node/Instead-of-Execution.html.

Sub-make is quite complex and requires ipc to support the -j flag my idea is to implement sub-make completely over ipc to simplify it.

Currently, if a rule references multiple targets, the Rule struct (and especially the recipe) is cloned for each target for storage inside the RuleMap, but we should instead store a vector of Rule objects, and reference them by index in the rule_lookup (HashMap). This is possible because rules are never removed from the RuleMap, they are only added during parsing of the makefile.

Hi :)

Did you know about makers? It has similar goals to omake, but incompatible license (I think), might be interesting for comparison and benchmarking.

Perhaps use different colors for warn vs err? Probably should do colors only if a tty is detected.

I think is-terminal is the best current Rust solution for providing isatty functionality cross-platform?

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.

Hi,

I would like to see a new filename available in MAKEFILE_SEARCH, in order to specify build configurations that use omake specific extensions. For example, Omakefile.

Also, are you sure that omake handles all BSD and GNU extensions to POSIX make? If not, then we should neither load BSDmakefile nor GNUmakefile, because such files are likely to present different syntaxes and/or semantics than omake uses.

Implement variables that are dynamically set during rule execution.

This should include POSIX $@, $%, $?, $<, $*, along with the GNU $^, $+, $|.