automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Static libraries not following the libfoo.a naming convention


From: Peter Rosin
Subject: Re: Static libraries not following the libfoo.a naming convention
Date: Thu, 23 Sep 2010 23:06:38 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2

Den 2010-09-23 20:59 skrev Ralf Wildenhues:
> Hi Peter,
> 
> * Peter Rosin wrote on Thu, Sep 23, 2010 at 10:01:16AM CEST:
>> I have been wondering when I was going to run into this problem,
> 
> Me too.

:-)

>> and
>> now it has happened (in the Libtool testsuite, tests/demo-deplibs.test).
> 
>> Automake has rules for creating static libraries like so (taken from
>> that test case):
>>
>> EXTRA_LIBRARIES = libhell0.a
>> libhell0_a_SOURCES =
>> libhell0_a_LIBADD = hello.$(OBJEXT) foo.$(OBJEXT)
> [...]
> 
>> Would it be possible for Automake to create static libraries of the
>> hell0.lib form, when it sees "*_LIBRARIES = libhell0.a"?
> 
> Yes, I think that should be possible in principle.  At least as long as
> all possible libraries to be built are known at automake run time.
> (This means, that if there are any @substitutions@ in *_LIBRARIES
> variables, as for example in tests/condlib.test tests/subst3.test
> tests/substtarg.test, then all possible values must either be listed
> in some EXTRA_*LIBRARIES variable, or the user must specify a rule to
> update the library.)
> 
>> Since there
>> might be 3rd party dependencies assuming the libhell0.a form, it
>> might be good if Automake also copied the hell0.lib file to
>> libhell0.a after creating libraries of the hell0.lib form to satisfy
>> those dependencies. (Or a symlink might suffice?)
> 
> I haven't made up my mind yet on the exact semantics.  There are a few
> possibilities, but portability and practicality will probably rule some
> of these out.
> 
> ATM I'm wondering whether completing AM_PROG_AR first or looking into
> this would be better.  AM_PROG_AR creates lots of fallout in Libtool
> beside the remaining work in Automake, and fixing Libtool so that it
> works well with older and newer Automake isn't exactly trivial.

Hi Ralf,

Yes, let's put this at the back of the queue.  I just figured I'd bring
it up, and it was nice to hear that it isn't completely impossible.

Cheers,
Peter



reply via email to

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