the samba4 build system

[Andrew Bartlett]

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
> things...

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.  

Andrew Bartlett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20040823/8d831909/attachment.bin