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
