[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,


> 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 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 file (a metadata file as I saw it) that it 
depends on 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 then the final "link" command should be something along 
the files of:
ld ... -llibconvenience2.a -llibconvenience1.a (because it had in that it depends on

But if the installable executable/library has LDADD/LIBADD on both and (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 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 :      WWW:
                        "Linux is obsolete" -- AST

reply via email to

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