Re: Static library naming

[Peter Rosin]

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.

>> but it *feels* wrong and non-native. Besides, Libtool creates
>> hello.lib and hello-0.dll when it builds Libtool libraries
>> using MS tools. Automake ought to also follow the naming
>> convention of the platform.
>>
> That might be something to be considered for Automake-NG, where we
> are anyway breaking backward-compatibility and changing some user
> level APIs (albeit "not too much", hopefully).  I'd say "please open
> a bug report, so we won't forget about the issue", but then I
> remember Automake-NG still lacks a dedicated bug tracker :-(  Which
> makes me realize it's time to get one at last; any help in doing so
> would be appreciated.
> 
>> So, since nothing is impossible, the question is how
>> impossible it would be to beat Automake into creating
>> hello.lib from the above rule?
>>
> Assuming we can change APIs and require GNU make (3.81 or later),
> how would you suggest to proceed?  If we manage to find a workable
> and simple approach, we could implement it in Automake-NG.

I have no insight into how much easier GNU make makes this.
So, I can't really comment on all sides of how "bad" it would
be to require Automake-NG. My concern here is not that GNU
make isn't available (it typically is), but instead that you
would have to use Automake-NG to implement this feature in
the build system. That would mean that projects concerned
most with portability (i.e. those not switching to Automake-NG
because they're not willing to abandon vendor makes) will not
have a way to properly support MS tools on Windows. I.e. those
maintainers most likely to accept these portability changes
will have no simple way to do so, as they would have to select
which kind of portability is most important: vendor makes or
the best MS support available.

>> Then there's the problem with other mentions of libhello.a,
>> such as in build rules and dependencies for other libraries.
>>
>> The only way I can see this working is to create something
>> like @libhello_a@ in Makefile.in for all mentions of
>> libhello.a in Makefile.am, and then have configure replace
>> that with libhello.a or hello.lib when it creates the final
>> Makefile.
>>
>> But that will probably crash and burn when conditionals
>> and variables etc are entered into the mix...
>>
> Yeah, I think we don't really want to go there.  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 (and that the reason for going
to Automake-NG would be this API-break)?

Cheers,
Peter