handling target specific flags in smb_build

Stefan Metzmacher metze at samba.org
Sun Jun 5 08:19:49 GMT 2005


Am Sonntag, 5. Juni 2005 05:20 schrieb Andrew Tridgell:
> Metze and Jelmer,
>
> I am hoping to get your help in making a change to the smb_build
> system in order to be able to support the in-tree heimdal build, and
> also better support the in-tree building of tdb, ldb, talloc, ejs and
> other libraries that have both in-tree and out-of-tree lives.
>
> The things I am hoping to change are:
>
>   - turn subsystems into separate make targets
>   - target specific cflags
>   - let make do its own expansion of dependencies and object lists
>
> 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)

I think we can maybe do it more general, when we create rules for each 
target( also for each .o file, with that we can handle also header file 
dependencies, (that we also want to support).

so we can specify the extra flags per subsystem or module,
and all file in the subsystem will have this flags in there make rule.

> 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:
>
> BINARY_smbd_DEPEND_LIST = subsystem_PROCESS_MODEL \
> 			  subsystem_SERVER_SERVICE \
> 			  subsystem_CONFIG \
> 			  subsystem_LIBCMDLINE \
> 			  subsystem_LIBBASIC

that is what we had before jelmers rewritte of the build system, and that was 
one of my ideas...
(don't get me wrong jelmers changes were mostly ok, as the made other things 
easier....:-)

I think the idea to use virtual targets for all build system objects would be 
good,

I think we should try to prelink the subsystems into one .o file ( as the linu 
kernel does)

with that it would be also easier to create selfchecks for the build system.
we can run nm on the per subsystem .o files, and check if the manual specified 
dependencies are correct or not, and then give warnings if there's something 
wrong...
> which matches what is in smbd/config.mk. The normal make rules for
> dependencies then take care of the expansion for us.
>
> 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?
>
> 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?
>
> We could also adopt scons, but I am very reluctant to be reliant on
> python for building Samba.

give me a few days to comment on the whole stuff...
> PS: please don't suggest automake
never :-)
-- 
metze
--
Stefan (metze) Metzmcher <metze at samba dot org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20050605/38ea0606/attachment.bin


More information about the samba-technical mailing list