the samba4 build system

Stefan (metze) Metzmacher metze at
Mon Aug 23 08:33:10 GMT 2004

Hash: SHA1

Andrew Bartlett schrieb:

| On Mon, 2004-08-23 at 16:15, Stefan (metze) Metzmacher wrote:
|>Hash: SHA1
|>tridge at 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
| 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
| 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!

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)

so that the config.m4 files only have to call one line for a test.

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.

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

- --

Stefan Metzmacher <metze at>
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Thunderbird -


More information about the samba-technical mailing list