Re: automatic linker dependencies for helper-libs to solve undefined references?

[Ralf Wildenhues]

Hi Christian,

* Christian Nolte wrote on Tue, Nov 15, 2005 at 02:53:48PM CET:
> 
> I am really struggling on migrating a M$-VC project to an automake based
> one. This project has a deep folder-structure and really ugly
> dependencies over boundaries of the subfolders. For example:
> 
> - ---
> ./project
>       project/utils
>       project/utils/console
>       project/gfx
>       project/main
> ...
> - ---
> 
> So in this example it could be that the helper lib for
> folder project/utils/console has dependencies to project/gfx or
> project/main needs something from project/utils which itself needs
> project/console.
> 
> I understand that automake needs helper-libs to create Makefiles for
> subfolders. For every subfolder I create a helper-lib, for example for
> project/utils I write in the corresponding Makefile.am:

No, the helper-libs are not absolutely necessary.
Neither is it necessary to create one Makefile per directory.

You have several choices to attack your problem:

First, a question: you get undefined references for linking; is that
because the libs you create depend on each other mutually (A -> B -> A)?
If yes, then you can either 
- list some of them twice in the link line (*_LDADD) (ugly), or,
- reduce the number of convenience libraries, or even do away with them
  at all.

Note the first of these suggestions is because static libraries are only
searched once by the linker: for symbols which it has seen before but
not found a definition yet, an object which defines it will be included
in the output.  Listing everything twice is very ugly but gets that
usually done.  But I'd recommend against it.


If on the other hand you get undefined references because some library
is not _built_ at the time it is needed, you can
- change the order 'make' traverses the subdirectories by ordering the
  entries in SUBDIRS; note that you can use the dot '.' explicitly to
  choose when to build in the current directory.
- or use (partially) non-recursive Makefiles.

> I thought if the approach mentioned in the paper "Recursive make
> considered harmful" [1] might be a possible solution, which is also to
> be found in the automake manual as an alternative to subdirectories [2].

Definitely.  If you want to go that way:
- be sure to use a _recent_ Automake
- use the subdir-objects Automake option

You can, for example,

utils_src = utils/source1.cpp utils/...
main_src = main/main.cpp ...
noinst_PROGRAMS = main/project
main_project_SOURCES = $(main_src) $(utils_src)
main_project_LDADD = gfx/libgfx.a
noinst_LIBRARIES = gfx/libgfx.a
gfx_libfgx_a_SOURCES = gfx/gfxfoo.cpp ...

and it will work quite like in the nice paper[1].  :)
But this is only a suggestion; some people like one way better, some
people another.  You could also mix (have Makefiles only in some
directories).

I hope this helps a bit.

Cheers,
Ralf