Hi Ralf!
Den 2010-06-16 20:57 skrev Ralf Wildenhues:
let's cut the libtool list from replies, ok?
Sure.
* Peter Rosin wrote on Wed, Jun 16, 2010 at 02:30:47PM CEST:
Den 2010-06-14 22:40 skrev Ralf Wildenhues:
* Peter Rosin wrote on Mon, Jun 14, 2010 at 09:35:45AM CEST:
Running the tests are still an outright pain though, but I will try it.
But it might take some time, I'm not used to running them and msys
is...cumbersome.
You have several ways to make your life easier: first, read
tests/README. Use 'make -jN' for parallel execution. All of Automake's
tests should complete without user interaction; if they don't, then we
will introduce check-{non,}interactive just like we did with Libtool.
You can use recheck to only check failed tests, and use TESTS=... for
subsetting as indicated before.
The main trouble is setting up the environment. I have an old MSYS
install and the current MinGW install procedure seems to be in a
state of flux so I fear the upgrade, but I think I'm going to need
latest MSYS to stay sane while installing perl, autoconf etc. But
I'm just whining... I guess there is enough time before the
paperwork has gone all the way.
Some nits and questions:
+path_conv=
+
+# func_path_conf build_path
Another remark: beside the typo in the function description s/conf/conv/
can we s/path/file/g globally on your patch? The GNU Coding Standards
want us to speak of paths only for things like $PATH that consists of
potentially multiple 'file names'. Thanks.
I don't really like 'file' since the function also handles directories.
But I'm a push-over, so fixed. But for the record, this feels weird:
linker_opts="$linker_opts -LIBPATH:$file"
+ case $path_conv in
+ mingw)
+ path=`cmd //C echo "$path " | sed -e 's/"\(.*\) " *\$/\1/'`
I fail to understand what this sed script is for. Help?
It was the easiest I could come up with after experimenting a lot. That
wasn't yesterday though, but IIRC if you want to convert paths with
spaces, you need to quote the $path for cmd, hence the quotes in the
echo "$path " construct. The space before the end quote will make the
argument always contain a space which forces MSYS to add quotes when the
path is fed to the Windows process (cmd in this case).
We rely on 'echo' not interpreting incoming backslashes here, right?
Is this something we need to be cautious over, or can 'cmd' only ever
find echo programs that work this way? (IIRC all MinGW shells were
fixed to this end, but the echo called here is a stand-alone program
right?)
The echo in that command will be the cmd-internal echo command, and how
that echo behaves should be consistent.
The backslash before $ should not be necessary. The shell does not
expand a $ before a /, and the backslash makes me think you're trying
to sed-match a literal dollar.
Ok, zapped.
The quotes are
added by MSYS after converting the path to windows form. Without that
space, the string is only quoted if it happens to contain a space, so
view it as a canonicalizer. The sed script is there to remove those
quotes (and the space before the end quote). Also, something seem to
mysteriously add a space at the end, so I'm removing that too while at
it, but only if it's really there (it felt like a bug that might be
fixed at some point). It might be possible to use eval to remove the
quotes, but since the path will typically contain backslashes I didn't
want to go there.
Yes, eval sounds very wrong, and more dangerous, too.
This explanation of yours lends itself nicely to a testsuite addition
that exercises the 'compile' script (no need to go through Autoconf or
Automake indirections), as in
cp $testsrcdir/../lib/compile .
./compile ... "weird\path\that\has\backslash-t.c" ...
...
If you create a script named .../cl that just dumps args you can test
that compile does the expected thing w/o having the real cl available.
I have a more general question though: for all of 'cmd //c', cygpath,
and wineconv, are their conversions idempotent? I.e., when I insert a
converted path, do they produce the same path again (a testsuite
addition could try to verify this). This might be necessary because we
have other pending patches for libtool that convert names to host format
there already, and those should not be broken.
If you look closely, the path conversion is only invoked if the path -
errmmh file - starts with a single forward slash, so we should be
completely safe if we are given pre-converted file names.
(I find it difficult is it to not say "path" when I refer to either
a directory or a file name, and so do you...)
The "cost" here is that users with weird mount tables (where a relative
file name does not mean the same thing in posix-land as it does in
windows-land) will not get the correct outcome.
But I really didn't do that optimization to cater for pre-converted
file names, I did it to save a fork in the common case (relative file
names and a "sane" mount table).
So, to answer you question, I think that the MSYS converter is safe
with Windows file names. I also think cygpath is generally safe, but
I'm sure there are also moronic cases which will not work (directories
named C: etc). For winepath I don't know.
--- a/NEWS
+++ b/NEWS
@@ -4,6 +4,9 @@ New in 1.11a:
- automake now generates silenced rules for texinfo outputs.
+ - The `compile' script now converts some options for MSVC to make the
+ user experience better.
Let's make that 'for a better user experience'. 'make' is such a bad
verb (sorry for the pun).
Sure, fixed.
+func_cl_wrapper ()
+{
+ # Assume a capable shell
+ linker_opts=
+ for arg
+ do
+ if test -n "$eat"; then
+ eat=
+ else
+ case $1 in
+ -o)
+ # configure might choose to run compile as `compile cc -o foo foo.c'.
+ eat=1
+ case $2 in
+ *.o | *.[oO][bB][jJ])
What about *.[oO]? Is that something we need to take into account?
I thought about that, but decided not to because .o is only there to
handle the (theoretical?) case where the project is totally unixy (not
even using $objext) and in that case the likelihood of .O seems very
remote. I simply didn't think .O would ever appear. What do you think?
Should I keep attaching the "current" version of the patch?
Cheers,
Peter
commit 06770d9fb9231014f7066d7f79aa7c1fa8d21ea1
Author: Peter Rosin <p...@lysator.liu.se>
Date: Wed Jun 16 22:21:36 2010 +0200
Wrap some MSVC options in the compile script.
* lib/compile: MSVC supports naming the output file, the option
is just not called -o, so transform -o into the appropriate form
for MSVC. Also wrap some other options while at it (-L, -l, -Wl,
-Xlinker and -I) and convert file names to windows form where
needed for those options to make MSVC more usable in an
autotooled environment.
* doc/automake.texi (Auxiliary Programs): Document the above
extension of the compile script.
* NEWS: Updated.
diff --git a/ChangeLog b/ChangeLog
index b5f1433..1eeacd4 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,16 @@
+2010-06-16 Peter Rosin <p...@lysator.liu.se>
+
+ Wrap some MSVC options in the compile script.
+ * lib/compile: MSVC supports naming the output file, the option
+ is just not called -o, so transform -o into the appropriate form
+ for MSVC. Also wrap some other options while at it (-L, -l, -Wl,
+ -Xlinker and -I) and convert file names to windows form where
+ needed for those options to make MSVC more usable in an
+ autotooled environment.
+ * doc/automake.texi (Auxiliary Programs): Document the above
+ extension of the compile script.
+ * NEWS: Updated.
+
2010-06-13 Stefano Lattarini <stefano.lattar...@gmail.com>
Add useful comment in test script obsolete.test.
diff --git a/NEWS b/NEWS
index 13b28c0..ae290d5 100644
--- a/NEWS
+++ b/NEWS
@@ -4,6 +4,9 @@ New in 1.11a:
- automake now generates silenced rules for texinfo outputs.
+ - The `compile' script now converts some options for MSVC for a better
+ user experience.
+
* New targets:
- New `cscope' target to build a cscope database for the source tree.
diff --git a/doc/automake.texi b/doc/automake.texi
index f5ccca1..491fafe 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -2169,7 +2169,11 @@ These two files are used for de-ANSI-fication support
(obsolete
@item compile
This is a wrapper for compilers that do not accept options @option{-c}
and @option{-o} at the same time. It is only used when absolutely
-required. Such compilers are rare.
+required. Such compilers are rare, with the Microsoft C/C++ Compiler
+as the most notable exception. This wrapper also makes the following
+common options available for that compiler, while performing file name
+translation where needed: @option{-I}, @option{-L}, @option{-l},
+...@option{-wl,} and @option{-Xlinker}.
@item config.guess
@itemx config.sub
diff --git a/lib/compile b/lib/compile
index c0096a7..dc56ea0 100755
--- a/lib/compile
+++ b/lib/compile
@@ -1,9 +1,9 @@
#! /bin/sh
# Wrapper for compilers which do not understand `-c -o'.
-scriptversion=2009-10-06.20; # UTC
+scriptversion=2010-06-16.20; # UTC
-# Copyright (C) 1999, 2000, 2003, 2004, 2005, 2009 Free Software
+# Copyright (C) 1999, 2000, 2003, 2004, 2005, 2009, 2010 Free Software
# Foundation, Inc.
# Written by Tom Tromey <tro...@cygnus.com>.
#
@@ -29,6 +29,120 @@ scriptversion=2009-10-06.20; # UTC
# bugs to <bug-autom...@gnu.org> or send patches to
# <automake-patches@gnu.org>.
+nl='
+'
+
+# We need space, tab and new line, in precisely that order. Quoting is
+# there to prevent tools from complaining about whitespace usage.
+IFS=" "" $nl"
+
+file_conv=
+
+# func_file_conv build_file
+# Convert a $build file to $host form and store it in $file
+func_file_conv ()
+{
+ file=$1
+ case $file in
+ / | /[^/]*) # absolute file, and not a UNC file
+ if test -z "$file_conv"; then
+ # lazily determine how to convert abs files
+ case `uname -s` in
+ MINGW*)
+ file_conv=mingw
+ ;;
+ CYGWIN*)
+ file_conv=cygwin
+ ;;
+ *)
+ file_conv=wine
+ ;;
+ esac
+ fi
+ case $file_conv in
+ mingw)
+ file=`cmd //C echo "$file " | sed -e 's/"\(.*\) " *$/\1/'`
+ ;;
+ cygwin)
+ file=`cygpath -w "$file" || echo "$file"`
+ ;;
+ wine)
+ file=`winepath -w "$file" || echo "$file"`
+ ;;
+ esac
+ ;;
+ esac
+}
+
+# func_cl_wrapper cl arg...
+# Adjust compile command to suite cl
+func_cl_wrapper ()
+{
+ # Assume a capable shell
+ linker_opts=
+ for arg
+ do
+ if test -n "$eat"; then
+ eat=
+ else
+ case $1 in
+ -o)
+ # configure might choose to run compile as `compile cc -o foo foo.c'.
+ eat=1
+ case $2 in
+ *.o | *.[oO][bB][jJ])
+ func_file_conv "$2"
+ set x "$@" -Fo"$file"
+ shift
+ ;;
+ *)
+ func_file_conv "$2"
+ set x "$@" -Fe"$file"
+ shift
+ ;;
+ esac
+ ;;
+ -I*)
+ func_file_conv "${1#-I}"
+ set x "$@" -I"$file"
+ shift
+ ;;
+ -l*)
+ set x "$@" "${1#-l}.lib"
+ shift
+ ;;
+ -L*)
+ func_file_conv "${1#-L}"
+ linker_opts="$linker_opts -LIBPATH:$file"
+ ;;
+ -Wl,*)
+ arg=${1#-Wl,}
+ save_ifs="$IFS"; IFS=','
+ for flag in $arg; do
+ IFS="$save_ifs"
+ linker_opts="$linker_opts $flag"
+ done
+ IFS="$save_ifs"
+ ;;
+ -Xlinker)
+ eat=1
+ linker_opts="$linker_opts $2"
+ ;;
+ *)
+ set x "$@" "$1"
+ shift
+ ;;
+ esac
+ fi
+ shift
+ done
+ if test -n "$linker_opts"; then
+ linker_opts="-link$linker_opts"
+ fi
+ exec "$@" $linker_opts
+ exit 1
+}
+
case $1 in
'')
echo "$0: No command. Try \`$0 --help' for more information." 1>&2
@@ -53,6 +167,9 @@ EOF
echo "compile $scriptversion"
exit $?
;;
+ cl | *[/\\]cl)
+ func_cl_wrapper "$@" # Doesn't return...
+ ;;
esac
ofile=
