[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Recursive source inclusion
Re: Recursive source inclusion
Sun, 07 Dec 2008 23:30:07 +0100
Thunderbird 188.8.131.52 (X11/20081125)
Brian Dessent wrote:
Thanks Ralf for the example and Brian for the explanation. These are
exactly the things I missed in the documentation (it's just telling what
you cannot do - but not how automake wants you to do certain things).
I tried to change my .am files now - I'm at the point where libtool
totally screws up - but that should be a resolvable error.
Ralf Wildenhues wrote:
How about adding it to a convenience archive, and then adding that to
your build. In this case, add
noinst_LIBRARIES = libcore.a
libcore_a_SOURCES = core.c
to src/Makefile.am, and add
gtkapp_LDADD = ../libcore.a
to gtk/Makefile.am. Inside src/Makefile.am, ensure that files in the
current directory are built before recursing, e.g., by
SUBDIRS = . gtk
To expand on the logic here a little bit, the reason that you have to
use a library to communicate objects across different .am files is that
the name of an object built by automake is considered an implementation
detail and is not stable. Only the .am file that is responsible for
building the object knows for sure what its name and location will be,
as there are all kinds of things that could cause it to have to munge or
obfuscate the name.
If you take that conclusion a little farther you realize that it then
really only makes sense to think about automake-managed objects as
belonging to a library or a program (or both), but not lying about loose
and unassociated. This explains why your attempt to get the top-level
.am to compile the object by specifying "SOURCES = core.c" didn't do
There's probably a chance that you find this totally ridiculous: "Why do
I need to create a library just to refer to an object in another dir?"
For one thing remember that convenience libraries are never installed,
so it's not like this will ever exist outside of your build tree.
And here is where I would say that if it bothers you then you should
instead just consider "gtkapp_SOURCES = gtkapp.c ../core.c". But you've
ruled that possibility out for reasons unstated. I'm assuming it's
because core.c is used elsewhere as part of some other component or
something, but that's even more reason to express this situation as a
library: two or more things reusing the same code. Maybe there is a
better solution if we knew more of the details, but without them it's
hard to tell you anything more than "use a library."
There are two additional other things to consider: one, you could switch
to a non-recursive setup with just a single .am file (or possibly
multiple files that are 'include'-ed together to make one file) at which
point everything is visible to everything else without the need to use a
convenience archive in this way, though it still might make sense to
group logical components together.
And two, the .am file is meant to allow arbitrary Makefile syntax to be
used, so if you really want to build an object in one .am file and refer
to it in another you can go ahead and write the rules to do so just as
if you were writing any ordinary Makefile. Sometimes, that's what it
takes to do the job and that's the only way to do what you need. But in
this instance automake has a perfectly valid way of handling the
situation, so it really seems wrong to encourage coloring outside of the