fix installcheck for --program-transform-name
OK to apply? This fixes ./configure --program-prefix=g make all install installcheck and also causes the testsuite to be correctly rebuilt upon installcheck. Thanks, Ralf 2008-03-08 Ralf Wildenhues [EMAIL PROTECTED] Fix installcheck dependencies, fix for --program-transform-name. * Makefile.am (installcheck-local): Depend upon tests/atconfig and $(srcdir)/$(TESTSUITE). * tests/testsuite.at (_LIBTOOLIZE_TRANSFORM): New macro. (LT_AT_CHECK_LIBTOOLIZE): Use it to transform expout and experr files suitably. Index: Makefile.am === RCS file: /cvsroot/libtool/libtool/Makefile.am,v retrieving revision 1.230 diff -u -r1.230 Makefile.am --- Makefile.am 4 Mar 2008 21:25:48 - 1.230 +++ Makefile.am 8 Mar 2008 13:20:52 - @@ -523,7 +523,7 @@ $(TESTS_ENVIRONMENT) $(BUILDCHECK_ENVIRONMENT) $(TESTSUITEFLAGS) # Run the test suite on the *installed* tree. -installcheck-local: +installcheck-local: tests/atconfig $(srcdir)/$(TESTSUITE) $(CD_TESTDIR); \ CONFIG_SHELL=$(SHELL) $(SHELL) $$abs_srcdir/$(TESTSUITE) \ $(TESTS_ENVIRONMENT) $(INSTALLCHECK_ENVIRONMENT) $(TESTSUITEFLAGS) \ Index: tests/testsuite.at === RCS file: /cvsroot/libtool/libtool/tests/testsuite.at,v retrieving revision 1.51 diff -u -r1.51 testsuite.at --- tests/testsuite.at 1 Feb 2008 19:06:42 - 1.51 +++ tests/testsuite.at 8 Mar 2008 13:20:53 - @@ -57,10 +57,22 @@ ]) +# _LIBTOOLIZE_TRANSFORM(FILE) +# --- +# Fix the expected output of installed libtoolize in presence of --program-*. +m4_define([_LIBTOOLIZE_TRANSFORM], +[lt_name=`$ECHO $LIBTOOLIZE | sed 's,^.*/,,'` # restore font-lock: '' +sed s/^libtoolize/$lt_name/ $1 $1.t +mv -f $1.t $1 +])dnl + + # LT_AT_CHECK_LIBTOOLIZE(ARGS, [EXIT-STATUS = 0], [STDOUT = `'], [STDERR = `']) # - m4_define([LT_AT_CHECK_LIBTOOLIZE], -[AT_CHECK([LT_AT_LIBTOOLIZE([$1])], +[m4_if([$3], [expout], [_LIBTOOLIZE_TRANSFORM([$3])])dnl +m4_if([$4], [experr], [_LIBTOOLIZE_TRANSFORM([$4])])dnl +AT_CHECK([LT_AT_LIBTOOLIZE([$1])], [$2], [$3], [$4]) ])
Re: Libtool head test status
Hallo Ralf, On 8 Mar 2008, at 06:49, Ralf Wildenhues wrote: FWIW, here's the patch again but without mangling. OK? Yep, looks good to me. Please apply. 2008-03-07 Ralf Wildenhues [EMAIL PROTECTED] * tests/nonrecursive.at: Use -no-undefined for foo.la. * tests/recursive.at: Likewise. * tests/subproject.at: Likewise. * tests/lt_dladvise.at: For systems where undefined symbols are not allowed, to not try to load the module libdepend. [ mingw ]: Add to list of such systems. * tests/testsuite.at (_LT_AT_TRANSLATE_TEXT_OUTPUT): New macro, to translate line ending of expout and experr files suitable for host executables. (LT_AT_CHECK, LT_AT_NOINST_EXEC_CHECK): Use it. Report by Bob Friesenhahn. Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ PGP.sig Description: This is a digitally signed message part
Re: Libtool head test status
On Sat, 8 Mar 2008, Ralf Wildenhues wrote: Now, in that test, the toplevel configure script chooses $top_srcdir/INSTALL (yes, the text file) as install script. I suspect this is because you have /uhome/src/gnu/libtool-head in the $PATH, the beginning of testsuite.log reveals that. Why is that, did you add that manually? Something in 'make check' must be putting it there since it is certainly not anything I did. Perhaps automake does this in order to find its scripts? It would be much safer to invoke any subordinate scripts using full paths. Unfortunately, Windows does not observe case. As evaluated by 'ls -l' in msys, the INSTALL file has permissions -rw-r--r-- so it should not be accidentally executed. However, if I pass /uhome/src/gnu/libtool-head/INSTALL to msys on the command line, it is indeed executed. The same happens with Cygwin. Perhaps since the execute bits are quite unreliable under Windows, any file is deemed executable. This is the path setting in the shell that invoked the tests: Bob [EMAIL PROTECTED] ~/mingw/libtool-head $ echo $PATH .:/usr/local/bin:/activestate/bin:/mingw/bin:/bin:/c/program files/graphicsmagick-1.1.11-q16:/c/Program Files/Microsoft DirectX SDK (June 2007)/Utilities/Bin/x86:/c/Perl/bin/:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Program Files/Microsoft SQL Server/80/Tools/Binn/:/c/Program Files/Rational/common:/c/Program Files/QuickTime/QTSystem/:/c/Qt/4.1.4/bin:/c/bin:/c/Adabas/bin:/c/Adabas/pgm:/c/Program Files/OpenVPN/bin Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Libtool head test status
On Sat, 8 Mar 2008, Ralf Wildenhues wrote: Now, in that test, the toplevel configure script chooses $top_srcdir/INSTALL (yes, the text file) as install script. I suspect this is because you have /uhome/src/gnu/libtool-head in the $PATH, the beginning of testsuite.log reveals that. Why is that, did you add that manually? It seems that our build environment is extending the path. Both msys and cygwin are happy to execute INSTALL as a shell script if passed to it like a command. Something is clearly doing a case-insensitive search of the PATH to find 'install' and is then using what it found. This is interesting: MINGW = Bob [EMAIL PROTECTED] ~ $ export PATH=/uhome/src/gnu/libtool-head:$PATH Bob [EMAIL PROTECTED] ~ $ which install install is /bin/install Bob [EMAIL PROTECTED] ~ $ which INSTALL INSTALL is /bin/INSTALL Bob [EMAIL PROTECTED] ~ $ INSTALL INSTALL: too few arguments Try `INSTALL --help' for more information. Bob [EMAIL PROTECTED] ~ $ echo $SHELL /bin/sh Cygwin == velma:~% which install /usr/bin/install velma:~% export PATH=/uhome/src/gnu/libtool-head:$PATH velma:~% which install /usr/bin/install velma:~% rehash velma:~% which install /usr/bin/install velma:~% install install: missing file operand Try `install --help' for more information. velma:~% INSTALL /uhome/src/gnu/libtool-head/INSTALL: line 1: Installation: command not found ./#.emacs#: line 2: syntax error near unexpected token `;;' ./#.emacs#: line 2: ` ;; custom-set-variables was added by Custom -- don't edit or cut/paste it!' /uhome/src/gnu/libtool-head/INSTALL: line 4: syntax error near unexpected token `C' /uhome/src/gnu/libtool-head/INSTALL: line 4: `Copyright (C) 1994, 1995, 1996, 1999, 2000, 2001, 2002, 2004, 2005,' velma:~% echo $SHELL /bin/zsh velma:~% bash bash-3.2$ which install install is /usr/bin/install bash-3.2$ echo $PATH /uhome/src/gnu/libtool-head:/activestate/bin:/usr/local/bin:/usr/X11R6/bin:/usr/bin:/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:. bash-3.2$ export SHELL=/bin/bash bash-3.2$ which install install is /usr/bin/install bash-3.2$ which INSTALL INSTALL is /usr/bin/INSTALL bash-3.2$ INSTALL INSTALL: missing file operand Try `INSTALL --help' for more information. == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Libtool head test status
Ralf Wildenhues wrote: Now, in that test, the toplevel configure script chooses $top_srcdir/INSTALL (yes, the text file) as install script. I suspect this is because you have /uhome/src/gnu/libtool-head in the $PATH, the beginning of testsuite.log reveals that. Why is that, did you add that manually? On MinGW (under MSYS, where '.' is in the default PATH) I've always found it necessary to explicitly specify INSTALL=/bin/install when configuring/making packages -- not just libtool, but almost any autotooled package. Part of this is the '.'-in-path thing, coupled with the case-insensitive nature of the filesystem, plus the look for either foo OR foo.exe in each DIR of $PATH, before going to next DIR behavior. The nuances are slightly different on cygwin and msys. I've never had this happen on cygwin, though. -- Chuck
[patch #6448] [MSVC 7/7] Add MSVC Support
Follow-up Comment #2, patch #6448 (project libtool): Hi, I'd like to give my feedback on these 7 patches (applied against trunk svn). They work amazingly well, I have been compiling gstreamer and dependencies under msys using msvc... and I had to remove all the 'hacks' I previously added to the makefiles to make it compile properly. Apart from being libtool-ized, they don't require ANY makefile/configure modification to be compiled with msvc under msys (thanks for fixing all the cygwin vs msys issues also). Awesome work ! I don't know what more is needed to push these patches in, if you need more feedback, logs, etc... please ask. ___ Reply to this item at: http://savannah.gnu.org/patch/?6448 ___ Message sent via/by Savannah http://savannah.gnu.org/
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
On Sat, 8 Mar 2008, Edward Hervey wrote: Hi, I'd like to give my feedback on these 7 patches (applied against trunk svn). Thanks for the useful feedback. This is good news. Awesome work ! I don't know what more is needed to push these patches in, if you need more feedback, logs, etc... please ask. The current plan is to address remaining issues found in the 2.2 release before any new functionality is added. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
[patch #6448] [MSVC 7/7] Add MSVC Support
Follow-up Comment #3, patch #6448 (project libtool): Thanks very much for the feedback, I'm glad to hear about the success! Previously there has been requests to test how this patch series behaves on other systems (which are not supposed to be affected). So, you can help by checking for regressions on whatever other systems you have available. In particular, testing for regressions using the cccl script was requested, but I failed to get cccl to do anything useful in the libtool context. So, any cccl user out there could also help with testing. I think the lib-as-archiver patches (i.e. 1/7 and 6/7) are the most intrusive in the series and they should perhaps be held back. IIRC, the patches work well with AR=ar as well, so that would not hinder using MSVC as the compiler/linker. You can test that as well, if you like. Leaving out AR=lib should be equivalent to saying AR=ar. Cheers, Peter ___ Reply to this item at: http://savannah.gnu.org/patch/?6448 ___ Message sent via/by Savannah http://savannah.gnu.org/
