[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Automatic dependecy based compilation targets
From: |
Dizzy |
Subject: |
Re: Automatic dependecy based compilation targets |
Date: |
Mon, 12 Feb 2007 13:36:12 +0200 |
User-agent: |
KMail/1.9.5 |
On Saturday 10 February 2007 14:15, you wrote:
> Hello Mihai,
Hello
> Well. Neither is completely 100% portable; IIRC not even linking a
> convenience library into a program is (but that is a Libtool limitation
> that could be overcome, AFAIK). I don't see a way around you making
> sure you only incorporate each convenience library into an output at
> most once.
Thank you for your continous help.
I think what I need is that when I list a code dependency for a convenience
library (say libconvenience2_la_LIBADD=libconvenience1.la) it shouldn't
actually include the code (object files) of libconvenience1.a (because I
noticed it basically creates a .a file) into libconvenience2.a but it should
just note into libconvenience2.la file (a metadata file as I saw it) that it
depends on libconvenience1.la and when linking final targets (installable
libraries/executables) it should use those lists of dependencies.
I mean if the installable executable/library has LDADD/LIBADD on
libconvenience2.la then the final "link" command should be something along
the files of:
ld ... -llibconvenience2.a -llibconvenience1.a (because it had in
libconvenience2.la that it depends on libconvenience1.la)
But if the installable executable/library has LDADD/LIBADD on both
libconvenience2.la and libconvenience1.la (because I know it directly depends
on both of them) then the final link command should be either:
ld ... -llibconvenience2.a -llibconvenience1.a (assuming there would be some
logic into libtool to eliminate the duplicates noticing that there is no need
to list again libconvenience1.a)
or even ld ... -llibconvenience2.a -llibconvenience1.a -llibconvenience1.a
should work too if ld is smart enough (although here I assume you mean it's
unportable as one presumes ld will be able to deal with duplicate listing of
the same library code).
Now that I think of it I think I probably don't need convenience libraries at
all but just somehow manage lists of source files. So instead of declaring a
convenience library libconvenience1.la including the compiled code of some
source files I declare a variable covenience1_sourcefiles = list of source
files for it. Do that for every "convenience library" (notice the quotes now)
that I have. When a "convenience library" depends on code from another just
add that "convenience library" list of sources variable to the SOURCES of
this one. Then in the final targets just add to the target SOURCES variable
the variables that contain the sources for the ones it directly depends on.
Have to try this to see if it works :)
--
Mihai RUSU Email: address@hidden
GPG : http://dizzy.roedu.net/dizzy-gpg.txt WWW: http://dizzy.roedu.net
"Linux is obsolete" -- AST