handling target specific flags in smb_build

[Jelmer Vernooij]

Hi,

On Sun, Jun 05, 2005 at 01:20:29PM +1000, Andrew Tridgell wrote about 'handling target specific flags in smb_build':
> The reason we need this is that when building the heimdal part of the
> code we need different CFLAGS than when building the rest of the
> code. Specifically, we need a bunch of -I options so that we don't
> need to change the #include paths in the heimdal code. We can't just
> add these to the global CFLAGS, as we have at least one header file
> with the same name (config.h), plus it would be rather untidy to have
> to have a single huge CFLAGS.

> I initially tried to do this by using the following syntax:

>  target: TARGET_CFLAGS=-Isome/path -Isome/other/path

> which works fine in gnu make, but not sun make. On sun make you can do
> the same thing with:

>  target:= TARGET_CFLAGS=-Isome/path -Isome/other/path

> but neither works on aix make. So instead I am proposing that if a
> subsystem have a TARGET_CFLAGS override it will end up with this:

> target: $(TARGET_DEPS)
> 	TARGET_CFLAGS="some extra flags" $(MAKE) $(TARGET_DEPS)

> that is recursive make of course, which we have tried to avoid, but I
> can't see any other portable way to do this. It isn't the worst kind
> of recursive make though, as at least it doesn't change makefile or
> change directory, which is largely what makes the usual recursive make
> systems so nasty.

> In order to make all this work we will need subsystem targets. So at
> the moment the SUBSYSTEM::SERVER_SERVICE exists as just a bunch of
> macro defines in the makefile. I'd like to see it like this:

> subsystem_SERVER_SERVICE: $(SERVER_SERVICE_DEPS)

> that makes it possible to do 'make subsystem_SERVER_SERVICE', and also
> makes it possible to do the target specific cflags, using the method
> above.

> It should also make it possible to reduce the size of the generated
> Makefile a lot. For example, the generated fragment for building
> bin/smbd is currently over 380 lines long, due to the expansion of all
> the dependencies and object lists. It would be much more compact if it
> looked like this:
The reason they're currently expanded is because I was trying to get
them to build as static libraries (which turned out to be a
complicated mess, so I've abandoned the idea). I'll revert it.

> I started to have a look at how to make these changes in
> build/smb_build/ but got a big bogged down with how the dependency and
> object lists are built up. Do either of you two have time to have a
> look at this?
I'll have a look at it right now.

> Jelmer and I also discussed the possibility of adopting 'cons' as our
> build system. That is certainly an option, although it doesn't seem to
> support 'virtual' targets - it only seems to support targets that
> exist as a directory of a file. The whole of the Samba4 build is full
> of virtual targets so I'm not sure cons is a good fit. What do you
> think Jelmer, any ideas on how to cope with that?
I've played with cons a bit yesterday and tried to find other projects using 
cons. It appears that cons hasn't been actively maintained since 2001
and I couldn't find any projects using it. Most people appear to have
migrated to scons. 

We could "adopt" cons though and fix the couple of things we
need in it (or perhaps add something like cons to the build system?)

> We could also adopt scons, but I am very reluctant to be reliant on
> python for building Samba.

> PS: please don't suggest automake
How can it be bad, if it's RMS-approved ? ;-)

Cheers,

Jelmer

-- 
Jelmer Vernooij <jelmer at samba.org> - http://jelmer.vernstok.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.samba.org/archive/samba-technical/attachments/20050605/9355adf8/attachment.bin