Opened 17 months ago
Last modified 16 months ago
#18555 new task
Jamfile to other build system
| Reported by: | SamuraiCrow | Owned by: | |
|---|---|---|---|
| Priority: | low | Milestone: | Unscheduled |
| Component: | Build System/Jamfile Engine | Version: | R1/Development |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
If I were to make a Jam migration tool to build system (possibly based on the Ham source) would anybody be willing to switch to GN and Ninja? If so, how foolproof would the migration tool need to be? I'm thinking some hand-done conversions might be ok after the naïve conversion is done.
This is based on the investigation in the jamfile frustration thread.
Change History (4)
comment:1 by , 17 months ago
| Keywords: | Jam Ham Ninja GN removed |
|---|
comment:2 by , 16 months ago
That being the case, I'll look again at Ham v1 and see if I can remove some warts. I was kind of hoping to avoid jumping headlong into C++20. I was just starting to tire-kick at C++17. I suppose it would still be easier than fixing the bugs in original Jam.
comment:3 by , 16 months ago
Please don't. Jam is fitting our needs and there is no need to replace it.
What we need to do is better document our build rules so people can make sense of how Haiku is built from all its parts.
I suppose it would still be easier than fixing the bugs in original Jam.
Which bugs? In pretty much all cases where people reported supposed problems with Jam, we found out one of these cases:
- User error (such as missing a dependency for the Haiku build),
- The error had been fixed years ago (or decades ago) in another version of Jam and all we had to do was cherry pick the patch,
- The problem was a missing or incorrect dependency in our Jamfiles, that led to tools attempting to use generated files before they were generated.
You found yourself with a solution looking for a problem. The problem does not exist...
Ham was created to allow faster builds and have a cleaner codebase, and also (maybe more importantly) because it looked like a fun project to hack on). There aren't really any functional problems to solve with Jam.
I would not want to switch to GN, no. I don't think it's nearly as flexible as Jamfiles.
All other build systems I have previously seen are not flexible enough to compile operating systems with, or require workarounds. Linux and the BSDs are still using variants of "make", probably for just this reason.
It may be possible to replace Jam and our Jamfiles/Jamrules with some other custom setup that generates Ninja (probably something Python-based) but that's about it.