GithubHelp home page GithubHelp logo

omake's People

Contributors

gregschmit avatar mcandre avatar xadaemon avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar

Forkers

xadaemon

omake's Issues

Implement automatic variables

Implement variables that are dynamically set during rule execution.

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

Should this project use separate bin/lib?

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

Implement -i (--ignore-errors)

-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.

request: promote omake to a library

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!

Consider building a pseudo-AST/CST

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.

Clean up command line options.

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.

Improve memory usage of `RuleMap`

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.

De-couple `Makefile` and logging

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).

request: refine MAKEFILE_SEARCH

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 control flow

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.

Add a system to select features or sets of features

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.

request: option for strict POSIX parsing

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?

Auto-fill the `MAKE` variable.

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 special targets (especially `.PHONY` and `.IGNORE`)

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

Related project

Hi :)

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

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.