Fine grained object build and linking control

[Dizzy]

Hi there

(sorry for the long email)

I have a C++ autotools (autoconf 2.61, automake 1.10, libtool 1.5.22) project 
where the source files are distributed as follows:
/(project root)
/src
/src/common
/src/common/ipc
/src/common/network
/src/daemon1
/src/daemon2

"daemon1" and "daemon2" are examples of end targets (sbin_PROGRAMS).

"/src/common" generally tries to group files which may be used in common by 
other end targets (such as "daemon1" and "daemon2"). Notice that the same 
file name may exist in different directories (such 
as "/src/common/ipc/Tree.cpp" and "/src/common/network/Tree.cpp"). There are 
no problems of symbol collision at the C++ level because subdirectories 
in "common" generally correspond to namespaces thus "ipc::Tree" 
and "network::Tree" are 2 very different classes. Also there are also files 
in "src/common" directory itself (files that may not be grouped under their 
own subdirectory in "src/common").

Currently in each "src/common" directory we have a noinst_LTLIBRARIES target 
such as libnetwork.la in src/common/network/Makefile.am and libipc.la in 
src/common/ipc/Makefile.am and libcommon.la in src/common/Makefile.am. The 
current system has one big problem that one can either link to a whole 
subdirectory in "common" or not at all and this creates problems because some 
of the files in a subdirectory in "common" have additional dependencies that 
others do not and while the final target only need to use those others it 
will have to link with the whole bunch (example: if 
src/common/ipc/NetworkTree.cpp depends on src/common/network/Socket.cpp even 
if a target only wants other code from src/common/ipc, not the NetworkTree 
code they still have to also link to src/common/network/libnetwork.la because 
src/common/ipc/libipc.la depends on it).

Another big problem with the current system is that the code from common is 
not compiled just when needed and on a need only strict policy. Say 
if "daemon1" works on win32 but "daemon2" doesn't we just conditionally 
exclude the "daemon2" directory from src/Makefile.am SUBDIRS but that won't 
solve it as we also need to deal with code in src/common that may not build 
on WIN32 although it's only used by "daemon2" which is not build on WIN32 
anyway (so why try to build the "common" code for it).

I would like to configure automake so:
- code in "src/common" should be built only as needed by "daemon1" 
or "daemon2" (each final target should specifically list each object file it 
needs from "src/common")
- code in "src/common" should be linked on a per object basis and not a per 
subdirectory bases (or per noinst library basis) so that I eliminate any 
bloat and unneeded link dependency (each final target should only try to link 
into it the object files it needs and not whole noinst libraries)
- once compiled code for some source it shouldn't recompile it (a normal thing 
but read bellow what happens in some solutions I tried)

How can I do this ? I have tried the following ways (each with problems):

1. if I just list in src/daemon1/Makefile.am the paths to "../common/File.cpp" 
then automake will try to build locally (in src/daemon1) each such 
listed .cpp file; this has 2 problems: one that if 2 files from 
different "common" directories but with same file name are listed then of 
course automake errors and also automake will recompile each file listed in 
each "daemon" directory even if it was already compiled in another "daemon" 
directory (thus failing last requirement from above)

2. if I just add as LDADD to the "daemon" final target object files 
from "common" I have the problem of finding that object name as it seems 
automake creates object files in ".deps/ltlibraryname-Socket.o" and I don't 
know how portable is to use these names in Makefile.am of "daemon" 
directories; also it won't second requirement from above as sources 
from "common" directories are not only built as needed but they need to be 
built initially all then try to link their object files to the "daemon" 
targets

Please help with a solution for this problem, thank you!

-- 
Mihai RUSU                                      Email: address@hidden
GPG : http://dizzy.roedu.net/dizzy-gpg.txt      WWW: http://dizzy.roedu.net
                        "Linux is obsolete" -- AST