On 2012-10-02 16:37, Stefano Lattarini wrote:
> Hi Peter, sorry again for the delay.
>
> On 09/26/2012 10:40 AM, Peter Rosin wrote:
>> On 2012-09-25 21:33, Stefano Lattarini wrote:
>>> [Dropping Automake-NG list, from the next reply]
>>>
>>> On 09/24/2012 10:51 AM, Peter Rosin wrote:
>>>>
>>>> [MEGA-SNIP]
>>>>
>>>> Yes, because I don't want this to be Automake-NG only. But since
>>>> this scheme is opt-in, the compile script "must" be adjusted to
>>>> handle libhello.a anyway. And with an adjusted compile script, I
>>>> suppose the acceptable level of ugliness elsewhere is lowered, as
>>>> it only fixes the (mostly) cosmetic naming problem.
>>>>
>>> So, if I understand correctly, you're saying that at this point it's
>>> better and simpler to just adjust the 'compile' script? Or am I
>>> misunderstanding? (in which case, sorry to be so dense!)
>>
>> Short answer: No, not quite, I still would like the possibility to
>> have Automake generate hello.lib without jumping through hoops.
>> Sorry for not being clear enough.
>>
>> Long answer: I attempted to say that given the plan to require
>> projects to opt-in for hello.lib instead of hardcoding libhello.a,
>> the compile script has to accommodate those that don't opt-in and
>> thus also support the libhello.a naming.
>>
> OK, clearer now. This first step ("support the libhello.a name for
> those who don't opt-in") could also be done for Automake 1.12.5,
> if anyone is kind enough to provide a patch :-)
Attached (form maint).
> IMHO we should want to be clearer that something "magic" is
> going on. So something like "lib(hello)" would still be better.
> (Determining the final colour of the bikeshed is left as
> exercise to the user ;-)
The one with the brush gets to decide, as usual. :-)
Cheers,
Peter
>From f54c5b1304766778b691aa88475a10c68e41f058 Mon Sep 17 00:00:00 2001
From: Peter Rosin <p...@lysator.liu.se>
Date: Thu, 4 Oct 2012 00:08:26 +0200
Subject: [PATCH] compile: support libfoo.a naming when wrapping Microsoft
tools
There is a future plan to provide some means to have Automake
create static libraries that are named differently depending
on the system [1].
The background is that everyone has always named static libraries
libfoo.a, except the Redmond crowd who names them foo.lib, and
you have to jump through hoops to have Automake create libraries
named foo.lib in the land of non-GNU Windows while still creating
libfoo.a everywhere else.
However, there is probably no sane way to accomplish that system
dependent naming discussed in [1] without user intervention,
which makes it necessary to support the classic libfoo.a naming
when using Microsoft tools in the best possible way, for the
benefit of all projects today and for future projects not
opting in to whatever scheme is selected for the problem at
hand.
[1] http://lists.gnu.org/archive/html/automake/2012-09/msg00028.html
* lib/compile (func_cl_dashl): As a last resort, match -lfoo with
libfoo.a, if that file exist on the library search path.
* t/compile4.sh: Remove obsolescent workaround for the above.
* t/compile6.sh: Extend to check that libbaz.a is indeed found
when baz.lib and baz.dll.lib does not exist and that bar.lib
and bar.dll.lib are preferred over libbar.a.
Signed-off-by: Peter Rosin <p...@lysator.liu.se>
---
lib/compile | 7 ++++++-
t/compile4.sh | 8 --------
t/compile6.sh | 10 +++++++++-
3 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/lib/compile b/lib/compile
index 7b4a9a7..45cf039 100755
--- a/lib/compile
+++ b/lib/compile
@@ -1,7 +1,7 @@
#! /bin/sh
# Wrapper for compilers which do not understand '-c -o'.
-scriptversion=2012-03-05.13; # UTC
+scriptversion=2012-10-03.22; # UTC
# Copyright (C) 1999-2012 Free Software Foundation, Inc.
# Written by Tom Tromey <tro...@cygnus.com>.
@@ -112,6 +112,11 @@ func_cl_dashl ()
lib=$dir/$lib.lib
break
fi
+ if test -f "$dir/lib$lib.a"; then
+ found=yes
+ lib=$dir/lib$lib.a
+ break
+ fi
done
IFS=$save_IFS
diff --git a/t/compile4.sh b/t/compile4.sh
index 2e275a3..e5b5c57 100755
--- a/t/compile4.sh
+++ b/t/compile4.sh
@@ -70,14 +70,6 @@ $MAKE
./compile cl $CPPFLAGS $CFLAGS -c -o "$absmainobj" "$absmainc"
-# cl expects archives to be named foo.lib, not libfoo.a so
-# make a simple copy here if needed. This is a severe case
-# of badness, but ignore that since this is not what is
-# being tested here...
-if test -f sub/libfoo.a; then
- cp sub/libfoo.a sub/foo.lib
-fi
-
# POSIX mandates that the compiler accepts a space between the -I,
# -l and -L options and their respective arguments. Traditionally,
# this should work also without a space. Try both usages.
diff --git a/t/compile6.sh b/t/compile6.sh
index ee47c17..529f22c 100755
--- a/t/compile6.sh
+++ b/t/compile6.sh
@@ -47,6 +47,8 @@ for sp in '' ' '; do
mkdir lib
: > lib/bar.lib
: > lib/bar.dll.lib
+ : > lib/libbar.a
+ : > lib/libbaz.a
# Check if compile library search correctly
opts=$(./compile ./cl foo.c -o foo -L${sp}lib -l${sp}bar -l${sp}foo)
@@ -58,6 +60,7 @@ for sp in '' ' '; do
: > syslib/bar.lib
: > syslib/bar.dll.lib
+ : > syslib/libbar.a
# Check if compile finds bar.dll.lib in syslib
opts=$(./compile ./cl foo.c -o foo -l${sp}bar -l${sp}foo)
@@ -67,6 +70,11 @@ for sp in '' ' '; do
opts=$(./compile ./cl foo.c -o foo -L${sp}lib -l${sp}bar -l${sp}foo)
test x"$opts" = x"foo.c -Fefoo lib/bar.dll.lib $syslib/foo.lib -link -LIBPATH:lib"
+ # Check if compile falls back to finding classic libname.a style libraries
+ # when name.lib or name.dll.lib isn't available.
+ opts=$(./compile ./cl foo.c -o foo -L${sp}lib -l${sp}baz)
+ test x"$opts" = x"foo.c -Fefoo lib/libbaz.a -link -LIBPATH:lib"
+
mkdir lib2
: > lib2/bar.dll.lib
@@ -93,7 +101,7 @@ for sp in '' ' '; do
syslib2="$(pwd)/sys lib2"
LIB="$syslib2;$LIB"
- # Check if compile handles spaces in $LIB and that it prefers the order
+ # Check if compile handles spaces in $LIB and that it obeys the order
# in a multi-component $LIB.
opts=$(./compile ./cl foo.c -o foo -l${sp}foo)
test x"$opts" = x"foo.c -Fefoo $syslib2/foo.dll.lib"
--
1.7.9
