Drop `HDRSCAN` and use `cc -M -MF` instead
waddlesplash opened this issue · comments
The header-scanning system that the original Jam used, and which Ham partially (but not fully) implements to determine header dependencies, is quite outdated and often is one of the slowest steps for Jam to use. These days, most modern build systems let the C/C++ compiler report what headers a file used on last compilation directly, using the -M -MF flags to emit such lists. Somehow the general rules file and Ham should be modified to do this, too, to avoid rescanning headers manually (which often gets such dependencies incorrect leading to improper partial rebuilds.)
Thanks for this great tip! I'd like to adopt some kind of adoption mechanism for this, both for unexpected uses of HDRSCAN and for more exotic preprocessors that might not implement those flags (as that's a GNU flag as far as I can tell). I'll probably trigger this on the presence of a new variable, but I'll give it some thought. Thanks!
MSVC has an equivalent flag (but a different output format.) Basically all compilers support this, ninja requires it I think. (For that matter you might also look at just generating Ninja files to run actual builds with and let Ninja take care of this part too; it's much faster overall for rebuilds anyway.)
MSVC has an equivalent flag (but a different output format.) Basically all compilers support this,
ninjarequires it I think. (For that matter you might also look at just generating Ninja files to run actual builds with and let Ninja take care of this part too; it's much faster overall for rebuilds anyway.)
Huh, Ninja looks really interesting. It's already available on Haiku, so I'll definitely consider it for any future reworks. Using ninja looks like it would simplify a lot of the make phase and likely increase performance.
I've written Ninja generators from scratch before so feel free to shoot questions my way about it.
Err, how is this completed?
Err, how is this completed?
I had been planning since the beginning of the project to alter the architecture, but especially after your note about Ninja, now seemed like the best time, as last week all the Jam evaluation logic was completed.
After talking with @stippi last week and running through a proof-of-concept/motivation, we decided to move to a new architecture so that Ham could have a better value proposition than "less buggy Jam". Namely, all the evaluation logic (what was worked on previously) will be moved over, but the custom parser, test suite, and make phase will be replaced. The motivation for everything, tools that will be used , and features that will be added are discussed in ADR #8-13 (located in docs/development/decisions on the v2 branch).
I'm just beginning to transition the project issues/docs, and so this issue was closed because part of the rework is using Ninja directly, so this change is obsolete. I'd love to talk with you more since you have experience creating Ninja build systems (that will be the last part of the refactor), so you can shoot me an email if you have time.
Personally I prefer using either GitHub or IRC/Matrix rather than email directly. Drop me a line whenever.