Finishing v2
SamuraiCrow opened this issue · comments
Based on the fact that Generate Ninja (abbreviated GN) is the first open source generator for Ninja build, I suspect that it will serve as a reference for Ham v2. It may even be more effective than fixing the last blocking issue in v1.
GN generates a rule to keep the Ninja build file in sync with all the GN files and targets that feed into the resultant Ninja file. This suggests to me that GN functions as a callback from Ninja such that only Ninja build needs to be multithreaded. Any internal generator function can be invoked recursively from the file it generated as long as either the build file or the callback terminates.
Does this sound like it would be easier to debug in Ham v2? I'm willing to help out or do it on my fork if you don't have the time. I'm assuming that multithreading is the difficulty faced in v1.
Yes, that GN approach was why I made V2. V1 is not any faster than Jam because the file evaluation and dependency tree building are single threaded, and it's very difficult to make evaluating Jam code fast. The performance gain in V2 is that we can evaluate the Jamfile once and let Ninja re-evaluate incremental builds directly.
Unfortunately V2 is, frankly, nowhere near complete. The remaining features are listed here. Right now it can parse files and evaluate some constructs, but there's a lot more evaluation left and the Ninja translation is specced but not started.
There is definitely less work to do on V1 to make it functional. Unfortunately, there is quite a lot of work to do to make it better than Jam (caching evaluations, serializing the dependency tree).
I haven't worked on this in a while so if you would like to do work on either one you are more than welcome! I will help any way I can.
Ok. I'm looking at the version 2 issue list. It appears that variables and expressions make up many of the issues. I've worked on transpilers before so finding out any Ninja build equivalents seems to be next on the agenda. If there are none, I'll have to build a callback expression evaluator in the Ham code.
Another thing that may need working around is batching a whole bunch of jamfile targets into one Ninja build file like GN does it. That will give maximum parallelism.
The v2 branch in my fork has been updated to reflect my substitutes for flow control operations using Callback evaluations that will need to be embedded in Ham to add functionality that Ninja build doesn't have.
@SamuraiCrow Issues aren't open on your repo so I can't discuss this there, but I'm not sure I understand your approach to Ninja translation.
Are you trying to translate expressions in Ham like IFs into expressions in Ninja? I was hoping to do the entire evaluation within Ham, and then translate the result (a list of actions with inputs to execute) into Ninja code. This lets us:
- Execute constructs that are difficult to replicate in Ninja
- Skip the most expensive operations on incremental builds
@SamuraiCrow Issues aren't open on your repo so I can't discuss this there, but I'm not sure I understand your approach to Ninja translation.
Issue tracker activated.