automake
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]