[ adding automake-patches; this is
http://thread.gmane.org/gmane.comp.gnu.libtool.general/10927/focus=10954 ]
* Peter Rosin wrote on Mon, Jun 14, 2010 at 09:35:45AM CEST:
> Den 2010-06-12 10:05 skrev Ralf Wildenhues:
> >Well, I sort of figured that the 'compile' script could end up absorbing
> >quite a bit of the cccl functionality so to make it unneeded. But hey,
> >let's be honest, somebody would have to do this work, because I don't
> >have the resources to do it.
>
> Do you think something along these lines would be acceptable? It would
> remove the need of some patches on the pr-msvc-support branch...
The patch looks pretty good to me already, but is lacking additions for
ChangeLog, NEWS, and maybe doc/ and tests/ too.
Wrt. test suite exposure, here's my overall take on this for Automake:
Generally, the suite should try to cover each and every single code bit,
even error cases, as much as is feasible without big hassles. Of
course, that'll only be realistic if you take the union of test suite
runs over all sorts of systems (but if some system-specific part can be
emulated elsewhere, that's great of course). As a first step, if you
tell me that the patch fixes some failures of existing tests on some
system with
env CC=cl make check
then that is fine with me too; as far as we have this information, it
should be noted in the log entry.
I understand the Automake test suite takes very long on MinGW. As
long as patches are MSVC-specific, you don't need to run the whole
suite for every single patch. Make good use of 'recheck' and
subsetting, as described in tests/README; for example, if you're only
ever dealing with C code handling,
cd $top_srcdir/tests && set `grep -l CC *.test` && cd -
make -k check TESTS="$*"
should cut load by two thirds already.
If there are tests that evoke popups or other things requiring
interactivity, then we should invent a 'required' name for that
and a helper make rule to run only those tests, or the complement,
similar to how is done in Libtool (do you use that there BTW?).
Wrt. 'compile' not being used by default in packages not using
AM_PROG_CC_C_O: don't worry about that for the moment. It is a trivial
first approximation to install the 'compile' script somewhere and use
./configure CC='/usr/local/bin/compile cl'
Don't be tempted to add AM_PROG_CC_C_O to projects not needing it
otherwise. If Automake support for MSVC is significantly improved,
at that point it could for example just install the compile script by
default in any project using C, and have AC_PROG_CC already trigger
the "is this MSVC?" check without AM_PROG_CC_C_O.
Wrt. avoiding the uname fork&exec, that can for example be optimized
by passing an option to the compile script before the compiler argument.
This too can come later, when we know better what set of information is
needed in 'compile'.
Some nits and questions:
> + 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?
> + cygwin)
> + path=`cygpath -w "$path"`
IIUC cygpath is pretty much required to be present on Cygwin
installations, right? Can it fail though? Should $path retain its old
value if it does? Don't we want -m rather than -w for forward slashes
(which IIUC even MSVC programs should support) to avoid quoting issues?
path=`cygpath -m "$path" || echo "$path"`
> + wine)
> + path=`winepath -w "$path"`
winepath OTOH may not be present, so this should definitely fall back to
the unconverted path I think. And maybe the path_conv-setting code
check for presence of winepath.
> +# func_cl_wrapper cl arg...
> +# Adjust compile command to suite cl
> +func_cl_wrapper ()
> +{
> + # Assume a capable shell
> + 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 | *.obj)
> + func_path_conv "$2"
> + set x "$@" -Fo"$path"
> + shift
> + ;;
> + *)
> + func_path_conv "$2"
> + set x "$@" -Fe"$path"
> + shift
> + ;;
> + esac
> + ;;
> + -I*)
> + func_path_conv "${1#-I}"
> + set x "$@" -I"$path"
> + shift
> + ;;
> + -l*)
> + set x "$@" "${1#-l}.lib"
> + shift
> + ;;
> + -L*)
> + func_path_conv "${1#-L}"
> + export LINK="$LINK -LIBPATH:$path"
Is LINK a predefined variable? Does it come from libtool? Or from the
user or the system?
> + ;;
> + -Wl,*)
> + arg=${1#-Wl,}
> + save_ifs="$IFS"; IFS=','
> + for flag in $arg; do
> + IFS="$save_ifs"
> + export LINK="$LINK $flag"
> + done
> + IFS="$save_ifs"
For this, IFS needs to be initialized to default near the beginning of
the script (there is an embedded TAB in the last line):
nl='
'
IFS=" "" "$nl"
> + ;;
> + -Xlinker)
> + eat=1
> + export LINK="$LINK $2"
> + ;;
> + *)
> + set x "$@" "$1"
> + shift
> + ;;
> + esac
> + fi
> + shift
> + done
> + exec "$@"
There needs to be an 'exit 1' here, in case exec fails.
> +}
Cheers,
Ralf
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
