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

[Christian Nolte]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

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:

- ---
SUBDIRS = console
noinst_LIBRARIES = libutils.a
libutils_a_SOURCES = A.h A.cpp B.h B.cpp
noinst_HEADERS = A.h B.h
- ---

The only binary which shall come out lies in project/main. The
Makefile.am there looks like this:

- ---
noinst_LIBRARIES = libmain.a
libmain_a_SOURCES = A.h A.cpp B.h B.cpp

libmain_a_LIBADD =

noinst_PROGRAMS = project
project_SOURCES = main.cpp

project_LDADD = $(top_builddir)/project/main/libmain.a \
                $(top_builddir)/project/utils/libutils.a \
                $(top_builddir)/project/utils/console/libconsole.a \
                $(top_builddir)/project/gfx/libgfx.a \
                $(top_builddir)/project/main \
                -lm -lpthread
- ---

I have managed to create my Makefile.am's so that I get a compile-run
without errors but several 'undefined references' at the linker-stage.
As the project is a huge one with complex dependencies, I am struggling
to get the order of library-dependencies right.

The last thing I tried was to reduce the dependencies for the
project-binary in that I define the LDADD's for every top-directory so
that it contains the sub-directory helper libs. In this example it boils
down to:

- --- Makefile.am of project/utils:
SUBDIRS = console
noinst_LIBRARIES = libutils.a
libutils_a_SOURCES = A.h A.cpp B.h B.cpp
noinst_HEADERS = A.h B.h

libutils_a_LIBADD = $(top_builddir)/project/utils/console/libconsole.a\
- ---

and

- --- Makefile.am of project/main
noinst_LIBRARIES = libmain.a
libmain_a_SOURCES = A.h A.cpp B.h B.cpp

libmain_a_LIBADD =

noinst_PROGRAMS = project
project_SOURCES = main.cpp

project_LDADD = $(top_builddir)/project/main/libmain.a \
                $(top_builddir)/project/utils/libutils.a \
                $(top_builddir)/project/gfx/libgfx.a \
                $(top_builddir)/project/main \
                -lm -lpthread
- ---

As you can see, the helper-lib libconsole.a is no longer listed in
project_LDADD.

This is just an easy example and with such simple project-structures I
never have had any problems. But now it seems quite impossible to get
the helper-lib cross-references for this rather huge right.

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].

Is there something wrong with my approach here, or is automake simply
not able to resolve these library interdependencies?

Best regards,
Christian


[1]http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html
[2]http://www.gnu.org/software/automake/manual/html_node/Alternative.html#Alternative

- --

Christian Nolte

mailto:address@hidden or mailto:address@hidden

key : http://public.fh-wolfenbuettel.de/~noltec/christian-nolte.asc
or  : www.keyserver.net

      GPG-fingerprint:
      1088 6C2D 1496 0A34 D159 1108 08D8 C0D2 77E1 5BBC
- ----------------------------------------------------------------------
The Information Revolution will be fought on the command line.
- ----------------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFDeehsCNjA0nfhW7wRAm3JAKCGPoMLl69mIsoydAvXe4MJr3SvDgCeMYwt
5N72LJaaXEiOQRDL26x9NEs=
=7Dsz
-----END PGP SIGNATURE-----