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 :-)
> 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.
> 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?
> Thoughts?
>
> Cheers,
> Peter
>
Regards,
Stefano
