Re: Static library naming

[Stefano Lattarini]

On 09/23/2012 11:47 PM, Peter Rosin wrote:
> Hi Stefano!
> 
> Thanks for your input!
> 
> On 2012-09-20 16:36, Stefano Lattarini wrote:
>> Adding the Automake-NG list in CC: (see below for the motivation).
>>
>> On 09/20/2012 12:49 AM, Peter Rosin wrote:
>>> Hi!
>>>
>> Hi Peter.
>>
>>> When you write
>>>
>>> lib_LIBRARIES = libhello.a
>>>
>>> you express the desire to build an "hello" archive. Virtually
>>> everywhere such an archive is expected to be named, tada,
>>> libhello.a
>>>
>>> Enter Windows. When using any and all toolchains not
>>> originating from GNU, such an archive is expected to be named
>>> hello.lib instead.  Anyway, at least this is the case for
>>> Microsoft tools and I think the other major players follows
>>> MS on this.
>>>
>>> Sure, it still works to have libraries named libhello.a with
>>> MS tools (since the linker assumes that files with unknown
>>> extensions are object files, and archives happen to fit),
>>>
>>> [SNIP]
>>>
>> Then I'd say: if it ain't broken, don't fix it :-)
> 
> Well, it is currently broken in that the compile script does
> not find libhello.a for the compiler driver when given -lhello
> as input, but that's easily fixable of course. I have not
> added that code exactly because I think it is the wrong
> fix. There should not be any need for recognizing libhello.a
> when the file should have be named hello.lib from the start.
> 
> And, I didn't leave this "hole" in the compile script on a whim,
> as it fixes the last failure in the Libtool testsuite when using
> MS tools, and it would have been really nice to "finish" that
> part of the work. I didn't want to temporarily add libhello.a
> support to the compile script because it is usually so much harder
> to remove features than it is to add them. I.e. I want to see
> the path forward before adding extra stuff like that, as you end
> up not knowing when it is ok to remove the extra baggage.
>
Thanks for this further info, it clarifies the matter a bit.

[SNIP]

>> We might simply
>> document that the developer is expected to use proper indirections
>> if he wants to support the MS tools in its package.  So that our
>> developer declares (say):
>>
>>     lib_LIBRARIES = bar/foo  # No more bar/libfoo.a!
>>
>> and Automake will generate a make variable (say) $(am_lib_foo) or
>> $(libs/foo), that expands to 'bar/libfoo.a' when POSIX tools are
>> in use and to 'bar/foo.lib' when MS tools are in use.  And the
>> developer will be expected to use that variable to refer to the
>> built library in other recipes or dependency declarations.
>>
>> WDYT?
> 
> This sounds ok to me, it would require adding support to the
> compile script for -lhello -> libhello.a, but now we know why
> we need it and that we actually do need it. The only concern is
> that I'm not 100% happy with requiring Automake-NG, as outlined
> above. So, how much harder is it to support this kind of stuff
> in vanilla Automake? What are the obstacles? It looks just like
> variable expansion to me, and how broken can that be? Is it
> that a construct such as $(am_lib_foo) can't be portably used
> in every place it would need to?
> 
> Because you are surely not suggesting that support for the
> current
>       lib_LIBRARIES = libhello.a
> is going away over this, are you?
>
Actually, I was suggesting precisely that :-/

> (and that the reason for going to Automake-NG would be
> this API-break)?
>
Exactly -- I suggested doing it only for Automake-NG since such
a backward-incompatibility would be totally unacceptable in
mainline Automake.

But then it occurs to me: we could make my proposal perfectly
backward-compatibly by adding a new "special syntax" like:

    lib_LIBRARIES = &hello

that will do all the translations and variable setting I proposed
above, while continuing to support:

    lib_LIBRARIES = libhello.a

seamlessly (but now with a warning in the 'extra-portability'
category, starting from Automake 1.14 at least).

Does this sound better?

Regards,
  Stefano