How can I build a single component in Haiku without jam recompiling the entire source all the time?
E.g. for Tracker, I run a jam -q Tracker as per the Readme, from the tracker lib source in src/kits/tracker, but jam insists that all targets are outdated and need a rebuild:
...patience...
...patience...
...found 13677 target(s)...
...updating 1667 target(s)...
C++ ../../../generated/objects
I also read that this is a known issue in jam and people moved on years ago.
Do we really want to stick to a dead and unmaintained, slow and buggy build tool?
In the mid to long term, we might want to check out CMake, which was not in the state or even available when Haiku was conceived, but I understand there are more pressing issues at hand now.
Still, something like CMake would most probably speed up builds and make devs more productive, and the build server use less resources…
I experienced the same “issue” yesterday when working directly on Haiku source for the first times.
Someone in the chat told me that it does not build the entire source,but everything Tracker depends on,which is a big part of the OS.
It seems it doesn’t use the installed system libraries and headers,but instead builds its own versions from source to work with.
Also,if jam works fine for Haiku,I don’t see a need to replace it.
As far as I know,what Haiku uses isn’t the dead upstream Jam but an own maintained fork of it.
I’m not a fan of Jam but I wouldn’t call it buggy. I’m not sure why it’s rebuilding everything each time for you but jam -q -j8 Tracker works as expected on my Haiku machine.
This has been discussed many times in the past. There are mailing list threads from probably 10 years or so ago about it. I don’t recall the specifics but there were people who felt that cmake was incapable of handling some of the things that jam does at build time. In any case, jam is already scheduled to be replaced by ham. It was worked on as part of the GSOC(?) last year but it’s not ready to be used.
ah I see, thanks @nipos for the details - I feared thus,-).
and thanks @Lrrr for the broader picture, didn’t want to start another tool discussion, was just a bit disappointed. I remember something about ham, will keep an eye on the progress there.
Looks good and I’ve starred it in the past already I see, but it depends on Python…
Curious how it performs but the list of reference projects looks good…
Incremental rebuilds work fine here, do they not work properly for you? As others already noted, building Tracker will also build all libraries Tracker depends on. In the log excerpt you posted, we can clearly see Jam is going to do an incremental build: “found 13677 targets, updating 1667 targets”.
CMake is really not fun to work with; it’s fine for high-level projects with straightforward setups, but when you have custom tools, dependencies, multiple compilers, etc. it’s really not ideal. Jam is actually a pretty good build language all things considered, we could just use a better interpreter for it.
Incremental build do not work properly with Jam currently. It still builds a lot of things that takes minutes even if nothing changed. And “patience” step takes a lot of time compared to meson/ninja.
Ideally incremental build should do literally nothing if nothing is changed. It should not attempt to rebuild catalogs, HPKGs and install image.
Yes, but this can be at least partially optimized; and I think it should be possible to get a tool (a future version of ham, probably) to generate Ninja files, which will fix that problem.
These get rebuilt if you rebuilt libroot_build and associated tools for any reason. If libroot_build wasn’t rebuilt, it doesn’t rebuild these.
This one it does always do, but I’m not sure why. There is even a variable in our Jam code called HAIKU_DONT_REBUILD_PACKAGES which you can set by passing -sHAIKU_...=1 to Jam, which will stop it from rebuilding the packages. So the rebuild-every-time behavior looks intentional somehow; but I haven’t dug into why that is.
This happens because the HPKGs are rebuilt, I think.