Re: The automake/libtool way to make a dynamic lib from multiple sources
On Thu, 2006-09-28 at 13:06 +0200, Ralf Wildenhues wrote: > Hello Ryan, > > * Ryan McDougall wrote on Thu, Sep 28, 2006 at 11:30:32AM CEST: > > On Thu, 2006-09-28 at 18:23 +0900, Ryan McDougall wrote: > > > > > > How can I either > > > 1. Express to automake the correct dependancy > > By writing > libA_la_LIBADD = libfoo.la > > instead of > libA_la_LIBADD = -L. -lfoo > > > I just discovered that I can trick automake with this: > > > > zardir=/dev/null > > zar_LTLIBRARIES=libfoo.la > > lib_LTLIBRARIES=libA.la > > > > and this will allow libfoo to be built before libA, however this is sort > > of trickery is bound to bite me in the ass somewhere, right? > > That is wrong, as it causes libfoo to not be a convenience archive, but > a real, installable library. It's doomed to failure, as the installed > libA may depend on it being present. > > Cheers, > Ralf > Cheers, everything works as I need it to to get the basic build up! Thanks for all your help Ralf! For the sake of those that google after me, here is my solution: In the directory containing the target library directories, and the dependent library directories I have the following Makefile.am AUTOMAKE_OPTIONS = subdir-objects noinst_LTLIBRARIES = lib_LTLIBRARIES = include libfoo/Makefile.am include libbar/Makefile.am include libA/Makefile.am within the dependent library directories I have the following Makefile.am noinst_LTLIBRARIES += libfoo.la libfoo_la_CPPFLAGS = -Ilibfoo/include libfoo_la_SOURCES = libfoo/src/libfoo.cpp within the target library directories I have the following Makefile.am lib_LTLIBRARIES += libA.la libA_la_LIBADD = libfoo.la libA_la_CPPFLAGS = -DIMPORTANT_COMPILE_TIME_SWITCHES \ -IlibA/include \ -Ilibfoo/include libA_la_SOURCES = libA/src/libA.cpp
Re: The automake/libtool way to make a dynamic lib from multiple sources
* Ryan McDougall wrote on Thu, Sep 28, 2006 at 11:23:10AM CEST: > > I am currently attempting to use a version of this (non-recursive) > method. I am avoiding exactly what you wrote since I need to pass > specific -D options to different packages without using libA_CPPFLAGS = > -DFORLIBFOO -DFORLIBBAR -DETC. What's the problem exactly here? Is there any thing you still need to solve, or not? Cheers, Ralf
Re: The automake/libtool way to make a dynamic lib from multiple sources
Hello Ryan, * Ryan McDougall wrote on Thu, Sep 28, 2006 at 11:30:32AM CEST: > On Thu, 2006-09-28 at 18:23 +0900, Ryan McDougall wrote: > > > > How can I either > > 1. Express to automake the correct dependancy By writing libA_la_LIBADD = libfoo.la instead of libA_la_LIBADD = -L. -lfoo > I just discovered that I can trick automake with this: > > zardir=/dev/null > zar_LTLIBRARIES=libfoo.la > lib_LTLIBRARIES=libA.la > > and this will allow libfoo to be built before libA, however this is sort > of trickery is bound to bite me in the ass somewhere, right? That is wrong, as it causes libfoo to not be a convenience archive, but a real, installable library. It's doomed to failure, as the installed libA may depend on it being present. Cheers, Ralf
Re: The automake/libtool way to make a dynamic lib from multiple sources
On Thu, 2006-09-28 at 18:23 +0900, Ryan McDougall wrote: > On Fri, 2006-09-22 at 04:34 +0200, Ralf Wildenhues wrote: > > * Ryan McDougall wrote on Fri, Sep 22, 2006 at 02:54:21AM CEST: > > > On Thu, 2006-09-21 at 13:32 +0200, Ralf Wildenhues wrote: > > > > * Ryan McDougall wrote on Thu, Sep 21, 2006 at 11:40:37AM CEST: > > How can I either > 1. Express to automake the correct dependancy > 2. Trick automake into building lib_LTLIBRARIES last (after > noinst_LTLIBRARIES) > I just discovered that I can trick automake with this: zardir=/dev/null zar_LTLIBRARIES=libfoo.la lib_LTLIBRARIES=libA.la and this will allow libfoo to be built before libA, however this is sort of trickery is bound to bite me in the ass somewhere, right? Cheers,
Re: The automake/libtool way to make a dynamic lib from multiple sources
On Fri, 2006-09-22 at 04:34 +0200, Ralf Wildenhues wrote: > * Ryan McDougall wrote on Fri, Sep 22, 2006 at 02:54:21AM CEST: > > On Thu, 2006-09-21 at 13:32 +0200, Ralf Wildenhues wrote: > > > * Ryan McDougall wrote on Thu, Sep 21, 2006 at 11:40:37AM CEST: > > > 2) If you prefer nonrecursive makefiles (you may include makefile > > > snippets from one into another), then you can just > > > > > > AUTOMAKE_OPTIONS = subdir-objects > > > module_LTLIBRARIES = libA.la libB.la libC.la > > > libA_la_SOURCES = foo/foo1.c bar/bar2.c A/a1.c ... > > > libB_la_SOURCES = baz/baz1/c bar/bar2.c B/b1.c .. > > > > I thought of this, but in this case libA_la_SOURCES could be on the > > order of 100-50 files long, which Id like to avoid if possible. > > You don't have to set this in one, and you can use variables (and > Automake conditionals) to factor. For example: > > -- Makefile.am -- > AUTOMAKE_OPTIONS = subdir-objects > module_LTLIBRARIES = libA.la libB.la libC.la > libA_la_SOURCES = > libB_la_SOURCES = > common_sources = > include foo/snippet.am > include bar/snippet.am > if CONDITION_BAZ > libB_la_SOURCES += baz/baz1.c > endif > libA_la_SOURCES += $(common_sources) > libB_la_SOURCES += $(common_sources) > > -- foo/snippet.am -- > ## Note the file name including the subdir here: we are being included > ## from a level up (Automake includes just do literal replacement): > libA_la_SOURCES += foo/foo1.c > > -- bar/snippet.am > common_sources += \ > bar/bar2.c \ > ... > Thanks for all your help Ralf, I _really_ appreciate you taking your time to help me out. I am currently attempting to use a version of this (non-recursive) method. I am avoiding exactly what you wrote since I need to pass specific -D options to different packages without using libA_CPPFLAGS = -DFORLIBFOO -DFORLIBBAR -DETC. What I have now is I have replaced the file names in the recursive Makefile.am's to be relative to the root directory like so: libfoo_SOURCES=src/foo.cpp -> libfoo_SOURCES=libfoo/src/foo.cpp and included libfoo/Makefile.am in the root Makefile.am. This works well, and would nearly be finished, except in my root Makefile.am I get this: noinst_LTLIBRARIES = libfoo.la ... lib_LTLIBRARIES = libA.la which Automake dutifully turns into a rule which always builds libA.la before libfoo.la, despite the fact that libA depends on libfoo (as expressed by the variable libA_la_LIBADD = -lfoo). How can I either 1. Express to automake the correct dependancy 2. Trick automake into building lib_LTLIBRARIES last (after noinst_LTLIBRARIES) ps. This would have been a lot easier if Automake would have automatically provided targets for each one of the SUBDIRS. That way I could have simply wrote one rule, libA: foo bar baz (where foo bar baz are SUBDIRs that need to be build before the SUBDIR libA). Should I open a bug/feature request? Thanks a tonne for your unheralded work!!! Id hate to have to give up on autotools. Cheers,
Re: The automake/libtool way to make a dynamic lib from multiple sources
* Ryan McDougall wrote on Fri, Sep 22, 2006 at 04:51:41AM CEST: > On Fri, 2006-09-22 at 04:34 +0200, Ralf Wildenhues wrote: > > > > The Libtool manual has more details about this (but it's arguably a bit > > cryptic about convenience archives). I'm not sure what you need to > > know. > > Since Im leaning to this method, Id like to investigate just what sort > of inefficiencies Im going to incur this way. You will have the overhead of one additional archiving step (ar + ranlib) and, on systems where one cannot pass whole archives to the linker to put in shared libraries (e.g., -Wl,--whole-archive with GNU ld), libtool will also extract that convenience archive one by one again. > Basically I don't know a whole lot about the details of dynamic > linking, so Id like to learn whats happening, if possible/reasonable. Hmm. Not sure what to recommend here. You can read the Libtool manual, after reading this nice (if not a bit old) book: http://www.iecc.com/linker/ > > You should not forget the libtool link flag -module (libA_la_LDFLAGS). > > This sounds interesting, is there a place I can read about this modules > bit? http://www.gnu.org/software/libtool/manual#Building-modules Cheers, Ralf
Re: The automake/libtool way to make a dynamic lib from multiple sources
On Fri, 2006-09-22 at 04:34 +0200, Ralf Wildenhues wrote: > > > > > > You should keep in mind that the convenience archives will end up in > > > total (i.e., all their symbols, not just needed ones) in the resulting > > > module. > > > > This is a good point, thank you. Do you have any more information > > somewhere that elaborates on this point? > > The Libtool manual has more details about this (but it's arguably a bit > cryptic about convenience archives). I'm not sure what you need to > know. Since Im leaning to this method, Id like to investigate just what sort of inefficiencies Im going to incur this way. Basically I don't know a whole lot about the details of dynamic linking, so Id like to learn whats happening, if possible/reasonable. > > > What is the "module" target? > > Oh, I forgot. If you install the modules in $(libdir), just use > lib_LTLIBRARIES; for the above to work you need something like > moduledir = $(libdir)/foo > > or similar (e.g., pkglibdir; or a setting in configure.ac). > > You should not forget the libtool link flag -module (libA_la_LDFLAGS). This sounds interesting, is there a place I can read about this modules bit? > > Cheers, > Ralf > Cheers,
Re: The automake/libtool way to make a dynamic lib from multiple sources
* Ryan McDougall wrote on Fri, Sep 22, 2006 at 04:10:40AM CEST: > > The problem with this is that with this method that I have to manually > specify the dependencies, right? > > A: foo > cd src/A && $(MAKE) $(AM_MAKEFLAGS) libA.la > .PHONY: A > > foo: > cd src/foo && $(MAKE) $(AM_MAKEFLAGS) libfoo.la > .PHONY: foo Yes, that would be a bit ugly (as you'd be specifying the same information in more than one place). You could put the dependency in the makefile in src/A though: ../foo/libfoo.la: cd ../foo && $(MAKE) $(AM_MAKEFLAGS) libfoo.la .PHONY: ../foo/libfoo.la (The phony qualifier is because the rule does not list the real dependencies of libfoo.la). Mind you though that this approach will cause more `make' instances to be invoked than necessary; depending on the size of the foo/Makefile this may be slowing down the build a bit. Generally, there are always trade-offs between recursive and nonrecursive make setups. Both have their merits and their backdraws, there's Peter Miller's classic paper "Recursive Make Considered Harmful" and also some arguments for the other side in this thread http://thread.gmane.org/gmane.comp.sysutils.automake.general/7250 (some of the arguments there are specific to Automake-generated portable makefiles, as opposed to, say, hand-written makefiles for GNU make). Cheers, Ralf
Re: The automake/libtool way to make a dynamic lib from multiple sources
* Ryan McDougall wrote on Fri, Sep 22, 2006 at 02:54:21AM CEST:
> On Thu, 2006-09-21 at 13:32 +0200, Ralf Wildenhues wrote:
> > * Ryan McDougall wrote on Thu, Sep 21, 2006 at 11:40:37AM CEST:
> > >
> > 1) If you prefer recursive makefiles then you can have each directory
> > create one (or a number of) libtool convenience archives
> > (noinst_LTLIBRARIES), which you can merge into the real modules
> > (A_la_LIBADD = ../foo/libfoo.la)
> >
> > You should keep in mind that the convenience archives will end up in
> > total (i.e., all their symbols, not just needed ones) in the resulting
> > module.
>
> This is a good point, thank you. Do you have any more information
> somewhere that elaborates on this point?
The Libtool manual has more details about this (but it's arguably a bit
cryptic about convenience archives). I'm not sure what you need to
know.
> > 2) If you prefer nonrecursive makefiles (you may include makefile
> > snippets from one into another), then you can just
> >
> > AUTOMAKE_OPTIONS = subdir-objects
> > module_LTLIBRARIES = libA.la libB.la libC.la
> > libA_la_SOURCES = foo/foo1.c bar/bar2.c A/a1.c ...
> > libB_la_SOURCES = baz/baz1/c bar/bar2.c B/b1.c ..
>
> I thought of this, but in this case libA_la_SOURCES could be on the
> order of 100-50 files long, which Id like to avoid if possible.
You don't have to set this in one, and you can use variables (and
Automake conditionals) to factor. For example:
-- Makefile.am --
AUTOMAKE_OPTIONS = subdir-objects
module_LTLIBRARIES = libA.la libB.la libC.la
libA_la_SOURCES =
libB_la_SOURCES =
common_sources =
include foo/snippet.am
include bar/snippet.am
if CONDITION_BAZ
libB_la_SOURCES += baz/baz1.c
endif
libA_la_SOURCES += $(common_sources)
libB_la_SOURCES += $(common_sources)
-- foo/snippet.am --
## Note the file name including the subdir here: we are being included
## from a level up (Automake includes just do literal replacement):
libA_la_SOURCES += foo/foo1.c
-- bar/snippet.am
common_sources += \
bar/bar2.c \
...
-- end
> AUTOMAKE_OPTIONS=subdir-objects tells automake to build temporary
> objects ("foo.lo") in the sub directories
Yes.
> to improve build times?
No, I don't think so. Well. For one, subdir-objects appear cleaner to
some users (i.e., purely a matter of taste). Then, more often objects
are not renamed by Automake in subdir-objects mode. The option also has
an impact on the size of the generated Makefile.in, but I'm not sure it
can be said generally whether that's for the better or worse (depends
for example on whether per-target compile flags are used).
> What is the "module" target?
Oh, I forgot. If you install the modules in $(libdir), just use
lib_LTLIBRARIES; for the above to work you need something like
moduledir = $(libdir)/foo
or similar (e.g., pkglibdir; or a setting in configure.ac).
You should not forget the libtool link flag -module (libA_la_LDFLAGS).
Cheers,
Ralf
Re: The automake/libtool way to make a dynamic lib from multiple sources
On Thu, 2006-09-21 at 13:32 +0200, Ralf Wildenhues wrote: > > The second approach will enable you to > make libA.la > > in the toplevel directory. Otherwise, there is nothing that prevents > you from adding your own targets a la > A: > cd src/A && $(MAKE) $(AM_MAKEFLAGS) libA.la > .PHONY: A > > just as in ordinary makefiles. > > Cheers, > Ralf > The problem with this is that with this method that I have to manually specify the dependencies, right? A: foo cd src/A && $(MAKE) $(AM_MAKEFLAGS) libA.la .PHONY: A foo: cd src/foo && $(MAKE) $(AM_MAKEFLAGS) libfoo.la .PHONY: foo etc ... Cheers,
Re: The automake/libtool way to make a dynamic lib from multiple sources
On Thu, 2006-09-21 at 13:32 +0200, Ralf Wildenhues wrote:
> Hello Ryan,
>
> * Ryan McDougall wrote on Thu, Sep 21, 2006 at 11:40:37AM CEST:
> >
> > Im porting a large code-base from windows to linux, and attempting to
> > use autotools to do so. The code in SVN is essentially one big tree of
> > somewhat related modules -- lets call them foo, bar, etc (Projects under
> > MS VS). I need to produce 3 dynamic libraries that can be built from
> > those modules -- lets call them A.so, B.so, and C.so (Solutions under
> > VS). They depend on a non-overlapping, non-disjoint set of the source
> > code modules in the directory.
>
> non-overlapping, non-disjoint sounds a bit like a typo; is it?
> Or do you mean they just partially overlap?
Yes, that was me being tired and not having my brain entirely in
English. :)
>
> > Directories for A, B, and C also
> > contain .cpp files and appear in the same parent directory as foo, bar,
> > etc.
> >
> > Currently I have all directories building respective "foo.la"s --
> > including A.la, B.la, and C.la, and have them installing correctly.
> >
> > Problems:
> > - I dont need the foo,bar,etc constituent libraries, I just need A,B,C
> > libraries, which means I have to manually delete them from the install
> > location afterwords
>
> 2 possibilities:
>
> 1) If you prefer recursive makefiles then you can have each directory
> create one (or a number of) libtool convenience archives
> (noinst_LTLIBRARIES), which you can merge into the real modules
> (A_la_LIBADD = ../foo/libfoo.la)
>
> You should keep in mind that the convenience archives will end up in
> total (i.e., all their symbols, not just needed ones) in the resulting
> module.
This is a good point, thank you. Do you have any more information
somewhere that elaborates on this point?
>
> 2) If you prefer nonrecursive makefiles (you may include makefile
> snippets from one into another), then you can just
>
> AUTOMAKE_OPTIONS = subdir-objects
> module_LTLIBRARIES = libA.la libB.la libC.la
> libA_la_SOURCES = foo/foo1.c bar/bar2.c A/a1.c ...
> libB_la_SOURCES = baz/baz1/c bar/bar2.c B/b1.c ..
I thought of this, but in this case libA_la_SOURCES could be on the
order of 100-50 files long, which Id like to avoid if possible.
AUTOMAKE_OPTIONS=subdir-objects tells automake to build temporary
objects ("foo.lo") in the sub directories to improve build times?
What is the "module" target?
> > - I would like to be able to type "Make A" from the parent directory,
> > and have the build system figure out which among foo,bar,etc libraries
> > are needed by A and build them in the manner you would expect
>
> The second approach will enable you to
> make libA.la
>
> in the toplevel directory. Otherwise, there is nothing that prevents
> you from adding your own targets a la
> A:
> cd src/A && $(MAKE) $(AM_MAKEFLAGS) libA.la
> .PHONY: A
>
> just as in ordinary makefiles.
I already have this done, but I was hoping the was a more magic way to
do this.
>
> Cheers,
> Ralf
>
Thanks for all your help Ralf!
Cheers,
Re: The automake/libtool way to make a dynamic lib from multiple sources
Hello Ryan, * Ryan McDougall wrote on Thu, Sep 21, 2006 at 11:40:37AM CEST: > > Im porting a large code-base from windows to linux, and attempting to > use autotools to do so. The code in SVN is essentially one big tree of > somewhat related modules -- lets call them foo, bar, etc (Projects under > MS VS). I need to produce 3 dynamic libraries that can be built from > those modules -- lets call them A.so, B.so, and C.so (Solutions under > VS). They depend on a non-overlapping, non-disjoint set of the source > code modules in the directory. non-overlapping, non-disjoint sounds a bit like a typo; is it? Or do you mean they just partially overlap? > Directories for A, B, and C also > contain .cpp files and appear in the same parent directory as foo, bar, > etc. > > Currently I have all directories building respective "foo.la"s -- > including A.la, B.la, and C.la, and have them installing correctly. > > Problems: > - I dont need the foo,bar,etc constituent libraries, I just need A,B,C > libraries, which means I have to manually delete them from the install > location afterwords 2 possibilities: 1) If you prefer recursive makefiles then you can have each directory create one (or a number of) libtool convenience archives (noinst_LTLIBRARIES), which you can merge into the real modules (A_la_LIBADD = ../foo/libfoo.la) You should keep in mind that the convenience archives will end up in total (i.e., all their symbols, not just needed ones) in the resulting module. 2) If you prefer nonrecursive makefiles (you may include makefile snippets from one into another), then you can just AUTOMAKE_OPTIONS = subdir-objects module_LTLIBRARIES = libA.la libB.la libC.la libA_la_SOURCES = foo/foo1.c bar/bar2.c A/a1.c ... libB_la_SOURCES = baz/baz1/c bar/bar2.c B/b1.c .. > - I would like to be able to type "Make A" from the parent directory, > and have the build system figure out which among foo,bar,etc libraries > are needed by A and build them in the manner you would expect The second approach will enable you to make libA.la in the toplevel directory. Otherwise, there is nothing that prevents you from adding your own targets a la A: cd src/A && $(MAKE) $(AM_MAKEFLAGS) libA.la .PHONY: A just as in ordinary makefiles. Cheers, Ralf
