What we observed for a very long time when cross-compiling samba4 for openwrt is that "waf install" without --targets will always do a full rebuild, ignoring any previously build "waf build --targets" run.
Actually "waf install" seems to always repeat what "waf build" did, so if we invoke "waf build" and than "waf install" with the exact same --targets set, we see 2 identical build runs.
What we would expect is that "waf install" only installs previously build targets.
So to fix this we skip the "waf build" step altogether and directly use "waf install --targets" to ensure only the targets we want are build/installed and prevent doing the same build twice in a row.
AFAIK it's been that way ever since Samba moved to waf build. I don't know the details but there's something different about install vs build - build is designed to run the binaries from their build dir, and load all dependent shared libs (which are also built) from their respective build dir, and install is designed to make binaries that load shared libs from their prefix location.
Exactly, we have some magic to allow running in the source directory.
If you try to run the binaries from the source after a 'make install' then they (typically) don't work, you need to run 'make' again for in-tree work.
Thankfully 'make test' also triggers a rebuild.
"Exactly, we have some magic to allow running in the source directory."
So "waf install" for samba is actually designed to do the build + install, while "waf build" is only designed to get bins that can run from the build dir?
I checked the build scripts of some distros that cross-compile samba and all of them basically do a waf build and waf install, without ever running anything from the build dir. This is because any other build system works this way, yet for samba this means they do one unnecessary step and double the compile time + resource usage. Before i discovered this quirk our automated testing often would fail samba because it took like 30+ minutes to compile and failed some maximum timeout threshold.
So maybe make it more clear whats actually going on there and that in many cases you don't actually need to do the "waf build" step, while "waf install" is not the same as a "make install".
So some section that explicitly states this difference in the documentation.
Generally only a few (not sure exactly, say a couple of dozen, but certainly not every) files get re-compiled, and then the resulting re-link is done.
Either way, a 30min limit on Samba is always going to be tight, a typical compile on modern cloud hardware is ~20mins looking over our recnet build pipelines.
Without the extra "waf build" we are fine now, so please consider makeing this more clear.
As noted in many cases the "waf build" is a unnecessary waste of resources, mainly because its not clearly documented and somewhat misleading named. That's why i filed a bug, since i actually thought "waf install" should just install and not do a full rebuild, which i have never seen on any other build system, that's why this is confusing.
(In reply to andieq from comment #5)
waf install is not a full rebuild, it's just relinking. Other build systems with support for running binaries from the build directory are doing the same, eg automake.
If i cross-compile via "waf build" and without any changes run a "waf install" right after, it takes the same amount of time, so its not just re-linking. The output also clearly shows it literally does the same steps that "waf build" does.
This was always the case, since i started creating our samba4 package.
(In reply to andieq from comment #7)
yes, I just wanted to point out the general feature. If this is not working for cross-compilation, that's likely a deficiency.
Sure i now understand what is supposed to happen, need to retest what happens without cross-compiling.
Was around samba4.3-4 where i first encountered this issue, mainly because i did "waf build --targets=" and than if you use "waf install" it will ignore all previously defined/build targets and do a full rebuild anyway. So i had to also specify "waf install --targets=" and then noticed that the install step looked nearly identical to the build step.