the samba4 build system
abartlet at samba.org
Mon Aug 23 08:44:33 GMT 2004
On Mon, 2004-08-23 at 18:33, Stefan (metze) Metzmacher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Andrew Bartlett schrieb:
> | On Mon, 2004-08-23 at 16:15, Stefan (metze) Metzmacher wrote:
> |>-----BEGIN PGP SIGNED MESSAGE-----
> |>Hash: SHA1
> |>tridge at samba.org schrieb:
> |>| Metze,
> |>| I hit a problem today where the build system was producing a Makefile
> |>| that used -O2, even though I specified --enable-developer. So far I
> |>| have spent about an hour trying to find where the -O2 is coming from,
> |>| but have failed.
> |>| I think this indicates that the build system might be getting too
> |>| complex.
> |>Do you really think it's easier to find something like this with the samba3 configure.in?
> | Actually, I think it is.
> | In Samba3, we had one file we knew to grep though, and it was produced
> | by the relatively simple application of substitution on Makefile.in.
> | I think that it is better to put the entire configure system on a diet
> | (so many of the tests are unused, as I think jelmer proved at one
> | point),
> yes so many are unused! and the unused are all in build/m4/rewrite.m4
> ~ and put it back in one spot.
> that is a bad idea, because we'll lose the overview about what test is needed by what code!
> And this is what causes this to be so complex!
Except as the output is global!
> and to make it lees complex, rewrite.m4 will go and
> also I want to put complex tests into a seperate macro in a seperate file in build/m4/
> (simular to the aproach to move tests to seperate files in tests/ in samba3 or build/tests/ in
> samba4, but it bit more easier for the calling code)
I don't think this precedent applies. In that case, only the *tests*
are moved. The call to those tests is still in one place.
> so that the config.m4 files only have to call one line for a test.
I don't see how a shorter, more complex macro is 'easier to understand'.
> e.g. create just one macro for the whole krb5 tests
> | There are many good aspects of the new build system, but spreading the
> | configure tests to the four winds is not one of them, unfortunately :-(
> I think when the build system is complete, it will a good aspect that the tests are splitted, to the
> places where they logicaly belong to.
I really don't think it helps!
> e.g. when you look at ntvfs/posix/config.m4 and find a referenz to a test which checks for quotas,
> ~ you know that this test is only needed in ntvfs/posix/* and if not it can safely be removed.
> or when you find a test for strtoull() and strtouq() in lib/replace/config.m4 you know it's only
> used in lib/replace/
> And the main reason for having the most unused test not to be removed, is that I don't understand
> what I'll break by removing them, and with the old style there's really no change to understand this
Except that the tests are still globally available, and the complexity
is spread. We can define 'modularity' in many ways - but it should be
in such a way that is easier for the rest of us to understand.
I honestly think the build system is the single module, and should be
kept together, aside possibly from the list of .c files.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20040823/8d831909/attachment.bin
More information about the samba-technical