Re: Using getconf to set max_cmd_len

2007-06-17 Thread Ralf Wildenhues
Hi Charles,

* Charles Wilson wrote on Sun, Jun 17, 2007 at 10:20:24PM CEST:
> 
> Committed (to HEAD and branch-1-5).  my sendmail hiccuped when trying to 
> send the notification to libtool-commit for branch-1-5, though.  I can 
> try to reconstruct that message manually and send it, if you think it's 
> important to do so.  (the notification for HEAD went thru without a hitch)

No, it's not important.

Thanks,
Ralf




Re: distchecking without FC?

2007-06-17 Thread Noah Misch
Hi Ralf,

On Sat, Jun 16, 2007 at 11:13:36AM +0200, Ralf Wildenhues wrote:
> * Noah Misch wrote on Fri, Jun 15, 2007 at 02:42:04AM CEST:
> > If better, we could compromise between complexity
> > and redundancy by generating the list of files at `bootstrap' time.
> 
> If you've already tried this, please post the patch.  Thanks.

I gave this a whirl.  Having done so, I personally prefer the simplicity of the
literal patch.  What do you think?

2007-06-18  Noah Misch  <[EMAIL PROTECTED]>

* bootstrap: Generate tests/test-disk.mk.  Arrange to do this after
configuring most directories, but before configuring the top level.
* Makefile.am: Include tests/test-dist.mk.
(configure-subdirs, @DIST_MAKEFILE_LIST@, DIST_SUBDIRS): Delete.
(clean-local-legacy): Delete `config.log' in test directories.
* configure.ac (CONF_SUBDIRS, DIST_MAKEFILE_LIST): Delete.

diff -urp -X ../dontdiff lt-clean/bootstrap lt-autofdist/bootstrap
--- lt-clean/bootstrap  2007-03-25 07:12:42.0 -0500
+++ lt-autofdist/bootstrap  2007-06-17 17:55:03.0 -0400
@@ -161,9 +161,29 @@ LIBTOOLIZE=`pwd`/$auxdir/libtoolize
 export LIBTOOLIZE
 
 for sub in $reconfdirs; do
+  test "$sub" = . && continue
   $AUTORECONF --force --verbose --install $sub
 done
 
+# Generate a list of legacy test suite files to distribute.
+{
+  echo '# Generated by Libtool bootstrap.'
+  echo
+  find tests/*demo tests/*demo[0-9] -name '{arch}' -prune -o -type f \
+\( \
+  -name \*.[ch] -o -name \*.cpp -o -name \*.f -o -name \*.f90 \
+  -o -name configure -o -name configure.ac -o -name aclocal.m4 \
+  -o -name Makefile.am -o -name \*.in -o -name README \
+\) \
+-printf 'EXTRA_DIST += %p\n'
+} >tests/test-dist.mk
+
+# Bootstrap `.' last.
+case $reconfdirs in
+  . | '. '* | *' . '* | *' .') $AUTORECONF --force --verbose --install ;;
+esac
+
+
 # Autoheader valiantly tries to prevent needless reconfigurations by
 # not changing the timestamp of config-h.in unless the file contents
 # are updated.  Unfortunately config-h.in depends on aclocal.m4 which
diff -urp -X ../dontdiff lt-clean/configure.ac lt-autofdist/configure.ac
--- lt-clean/configure.ac   2007-03-26 15:18:43.0 -0500
+++ lt-autofdist/configure.ac   2007-06-17 17:15:30.0 -0400
@@ -153,18 +153,6 @@ if test x"${enable_ltdl_install+set}" !=
   enable_ltdl_install=yes
 fi
 
-# All subdirectories that are configured on demand, but that must be
-# included in the distribution.
-CONF_SUBDIRS="tests/cdemo tests/demo tests/depdemo tests/f77demo tests/fcdemo \
-   tests/mdemo tests/mdemo2 tests/pdemo tests/tagdemo"
-AC_SUBST([CONF_SUBDIRS])
-
-DIST_MAKEFILE_LIST=
-for dir in $CONF_SUBDIRS; do
-  DIST_MAKEFILE_LIST="${DIST_MAKEFILE_LIST}$dir/Makefile "
-done
-AC_SUBST([DIST_MAKEFILE_LIST])
-
 
 ##  ##
 ## compiler checks. ##
diff -urp -X ../dontdiff lt-clean/Makefile.am lt-autofdist/Makefile.am
--- lt-clean/Makefile.am2007-06-14 12:37:28.0 -0400
+++ lt-autofdist/Makefile.am2007-06-17 17:16:21.0 -0400
@@ -103,14 +103,6 @@ libtool: $(top_builddir)/config.status $
  cd $(top_builddir) && $(SHELL) ./config.status $$target; \
fi
 
-.PHONY: configure-subdirs
-configure-subdirs distdir: $(DIST_MAKEFILE_LIST)
[EMAIL PROTECTED]@:
-   dir=`echo $@ | sed 's,^[^/]*$$,.,;s,/[^/]*$$,,'`; \
-   test -d $$dir || mkdir $$dir || exit 1; \
-   abs_srcdir=`$(lt__cd) $(srcdir) && pwd`; \
-   (cd $$dir && $$abs_srcdir/$$dir/configure) || exit 1
-
 
 # -- #
 # Bootstrap. #
@@ -614,7 +606,7 @@ tests/demo-conf.test: libtool
 
 EXTRA_DIST += $(srcdir)/tests/defs.in tests/defs.m4sh \
  $(COMMON_TESTS) $(CXX_TESTS) $(F77_TESTS) $(FC_TESTS)
-DIST_SUBDIRS   += $(CONF_SUBDIRS)
+include tests/test-dist.mk
 
 # The defs script shouldn't be recreated whenever the Makefile is
 # regenerated since the source tree can be read-only.
@@ -632,12 +624,14 @@ $(srcdir)/tests/defs.in: $(auxdir)/gener
rm -f tests/defs.in; \
$(M4SH) -B $(auxdir) tests/defs.m4sh > tests/defs.in
 
-# We need to remove any files that the above tests created.
+# We need to remove any files that the above tests created.  Where 
configuration
+# failed, `config.log' will exist in the absence of `Makefile'.
 clean-local-legacy:
-cd tests; \
for dir in cdemo demo depdemo f77demo fcdemo mdemo mdemo2 pdemo 
tagdemo; \
do \
test -f $$dir/Makefile && ( cd $$dir && $(MAKE) distclean; ); \
+   rm -f $$dir/config.log; \
done
rm -rf _inst
 




Re: Using getconf to set max_cmd_len

2007-06-17 Thread Peter O'Gorman
On Sun, 2007-06-17 at 20:39 +0200, Ralf Wildenhues wrote:
> * Charles Wilson wrote on Sun, Jun 17, 2007 at 08:32:33PM CEST:
> > OK to apply (both branches)?
> 
> Of course.  Thanks.  And no need for my name in the ChangeLog entry.
> 
> Cheers,
> Ralf
> 
> > 2007-06-17  Charles Wilson  <...>
> > Ralf Wildenhues  <...>
> > 
> > * libltdl/m4/libtool.m4 (LT_CMD_MAX_LEN): ensure error is
> > redirected even when getconf does not exist.

I noticed that when I tried this with 'getconf' changed to some
non-existing utility I got errors from expr. Turns out that we need to
quote the string for test -n.

Applied to HEAD and branch-1-5.

Peter

2007-06-17  Peter O'Gorman  <[EMAIL PROTECTED]>

	* libltdl/m4/libtool.m4 (LT_CMD_MAX_LEN): add quotes to
	the test -n.

Index: libltdl/m4/libtool.m4
===
RCS file: /sources/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.106
diff -u -r1.106 libtool.m4
--- libltdl/m4/libtool.m4	17 Jun 2007 20:16:03 -	1.106
+++ libltdl/m4/libtool.m4	18 Jun 2007 00:42:17 -
@@ -1438,7 +1438,7 @@
 ;;
   *)
 lt_cv_sys_max_cmd_len=`(getconf ARG_MAX) 2> /dev/null`
-if test -n $lt_cv_sys_max_cmd_len; then
+if test -n "$lt_cv_sys_max_cmd_len"; then
   lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 4`
   lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \* 3`
 else


Re: [patch] win32: eliminate wrapper script in main build dir

2007-06-17 Thread Charles Wilson

Ralf Wildenhues wrote:

* Charles Wilson wrote on Sun, Jun 17, 2007 at 02:43:02AM CEST:
OK by me.  Do you wat me to add your patch to mine and check it all in 
at once (e.g. keep the new-testsuite .exe fixes to destdir.at together), 
or will you check your changes in separately?


However you like.


It is included below.


Attached.  Unless you beat me to it, I can try to go about a patch
sometime though.

In any case, I'd like to postpone the cross-compile old-testsuite .exe 
fixes to a followup patch.


Sure.


OK.

Updated patch attached, incorporating (I hope) all extant comments from 
Noah and Ralf, along with an updated ChangeLog.


This passes all expected tests on linux (native).

On cygwin (native) it fails 14,16,32, and 54, which is the expected 
behavior.


I'll test

[with
export INSTALL=/usr/bin/install.exe
to ensure that I don't get spurious failures for 35 39 43 46]

on mingw (native) before committing, and then commit tomorrow only if 
the failures are limited to the same as on cygwin, and there are no 
other objections.


--
Chuck

2007-06-17  Charles Wilson  <[EMAIL PROTECTED]>

* libltdl/config/ltmain.m4sh: Add new magic variable
for use with cwrapper.
(func_ltwrapper_script_p): New function.
(func_ltwrapper_executable_p): New function.
(func_ltwrapper_scriptname): New function.
(func_ltwrapper_p): Accomodate both wrapper scripts and
wrapper executables.
(func_mode_execute): Handle $file that is a wrapper
script and $file that is a wrapper executable differently.
(func_mode_install) [cygwin|mingw]: If $file is a wrapper
executable, use func_ltwrapper_scriptname to determine
wrapper script name. Afterwards, always use
func_ltwrapper_script_p instead of func_ltwrapper_p.
(func_emit_libtool_wrapper_script): Rename to...
(func_emit_wrapper): ...this. All callers changed.
(func_emit_libtool_cwrapperexe_source): Rename to...
(func_emit_cwrapperexe_src): ...this. All callers changed.
Embed new magic_exe variable into source. Private transient
wrapper script now called foo_ltshwrapperTMP, not
foo_ltshwrapper.
(func_emit_cwrapperexe_src) [main, mingw]: Use _spawnv
and return child's exit code manually rather than rely on
broken execv.
(func_mode_link) [cygwin|mingw]: Don't call dirname and
basename directly; use func_dirname and func_basename
when computing cwrapper names.  Use cwrapper to generate
wrapper script, and use pathname returned by
func_ltwrapper_scriptname instead of $output.
(func_mode_link) [NOT cygwin|mingw]: move wrapper script
generation for non-win32 inside case statement, as default
case.
(func_mode_uninstall) [$name's extension != .lo|.la]:
'clean' mode must handle $file differently if it is a libtool
wrapper script, or if it is a libtool wrapper executable.
* tests/destdir.at [Simple DESTDIR install]: $EXEEXT fixups.
* tests/destdir.at [DESTDIR with in-package deplibs]: Ditto.


Index: libltdl/config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.79
diff -u -r1.79 ltmain.m4sh
--- libltdl/config/ltmain.m4sh  9 Jun 2007 17:46:40 -   1.79
+++ libltdl/config/ltmain.m4sh  17 Jun 2007 18:02:16 -
@@ -135,7 +135,7 @@
 fi
 
 magic="%%%MAGIC variable%%%"
-
+magic_exe="%%%MAGIC EXE variable%%%"
 
 # Global variables.
 # $mode is unset
@@ -661,13 +661,55 @@
 test "$lalib_p" = yes
 }
 
+# func_ltwrapper_script_p file
+# True iff FILE is a libtool wrapper script
+# This function is only a basic sanity check; it will hardly flush out
+# determined imposters.
+func_ltwrapper_script_p ()
+{
+func_lalib_p "$1"
+}
+
+# func_ltwrapper_executable_p file
+# True iff FILE is a libtool wrapper executable
+# This function is only a basic sanity check; it will hardly flush out
+# determined imposters.
+func_ltwrapper_executable_p ()
+{
+func_ltwrapper_exec_suffix=
+case $1 in
+*.exe) ;;
+*) func_ltwrapper_exec_suffix=.exe ;;
+esac
+$GREP "$magic_exe" "$1$func_ltwrapper_exec_suffix" >/dev/null 2>&1
+}
+
+# func_ltwrapper_scriptname file
+# Assumes file is an ltwrapper_executable
+# uses $file to determine the appropriate filename for a
+# temporary ltwrapper_script.
+func_ltwrapper_scriptname ()
+{
+func_ltwrapper_scriptname_result=""
+if func_ltwrapper_executable_p "$1"; then
+   func_dirname "$1"
+   func_basename "$1"
+   func_stripname '' '.exe' "$func_basename_result"
+   if test -z "$func_dirname_result"; then
+   
func_ltwrapper_scriptname_result="./$objdir/${func_stripname_result}_ltshwrapper"
+   else
+   
func_ltwrapper_scriptname_result="$func_dirname_result/$objdir/${func_stripname_result}_ltshwrapp

Re: Using getconf to set max_cmd_len

2007-06-17 Thread Charles Wilson

Ralf Wildenhues wrote:

* Charles Wilson wrote on Sun, Jun 17, 2007 at 08:32:33PM CEST:

OK to apply (both branches)?


Of course.  Thanks.  And no need for my name in the ChangeLog entry.

Cheers,
Ralf


2007-06-17  Charles Wilson  <...>
Ralf Wildenhues  <...>

* libltdl/m4/libtool.m4 (LT_CMD_MAX_LEN): ensure error is
redirected even when getconf does not exist.


Committed (to HEAD and branch-1-5).  my sendmail hiccuped when trying to 
send the notification to libtool-commit for branch-1-5, though.  I can 
try to reconstruct that message manually and send it, if you think it's 
important to do so.  (the notification for HEAD went thru without a hitch)


--
Chuck




Re: [patch] win32: eliminate wrapper script in main build dir

2007-06-17 Thread Ralf Wildenhues
Hi Charles,

* Charles Wilson wrote on Sun, Jun 17, 2007 at 08:01:20PM CEST:
> Ralf Wildenhues wrote:
> >* Charles Wilson wrote on Sun, Jun 17, 2007 at 02:43:02AM CEST:
> 
> OK by me.  Do you wat me to add your patch to mine and check it all in 
> at once (e.g. keep the new-testsuite .exe fixes to destdir.at together), 
> or will you check your changes in separately?

However you like.

> >Grepping the verbose output of the old HEAD testsuite for 'No such file
> >or directory' shows several bits that need adjustment, too.
> 
> Well, this is a bit more excusable: INSIDE libtool, we're allowed to 
> depend on internal libtool details.  Even if it isn't a really good 
> idea, as in this case.
> 
> Notwithstanding the answer to my question above concerning 
> new-testsuite/destdir.at, I'd appreciate it if you would (at least) 
> provide me with your cross-compile verbose log from the old testsuite, 
> or (at best) a followup patch to fix these issues -- since I don't have 
> a cross-compile setup, here.

Attached.  Unless you beat me to it, I can try to go about a patch
sometime though.

> In any case, I'd like to postpone the cross-compile old-testsuite .exe 
> fixes to a followup patch.

Sure.

Cheers,
Ralf


checklog-old-suite.bz2
Description: Binary data


Re: Using getconf to set max_cmd_len

2007-06-17 Thread Ralf Wildenhues
* Charles Wilson wrote on Sun, Jun 17, 2007 at 08:32:33PM CEST:
> OK to apply (both branches)?

Of course.  Thanks.  And no need for my name in the ChangeLog entry.

Cheers,
Ralf

> 2007-06-17  Charles Wilson  <...>
> Ralf Wildenhues  <...>
> 
>   * libltdl/m4/libtool.m4 (LT_CMD_MAX_LEN): ensure error is
>   redirected even when getconf does not exist.




Re: Using getconf to set max_cmd_len

2007-06-17 Thread Charles Wilson

Ralf Wildenhues wrote:

* Steve Ellcey wrote on Thu, May 31, 2007 at 12:58:37AM CEST:

2007-05-30  Steve Ellcey  <[EMAIL PROTECTED]>

* libltdl/m4/libtool.m4 (LT_CMD_MAX_LEN): Try using getconf
to set lt_cv_sys_max_cmd_len.

[...]


+lt_cv_sys_max_cmd_len=`getconf ARG_MAX 2> /dev/null`


The patch is all good (thanks!) except someone please put `getconf
ARG_MAX' in a subshell so that if it does not exist, the shell error
output is redirected as well (both branches).


OK to apply (both branches)?

2007-06-17  Charles Wilson  <...>
Ralf Wildenhues  <...>

* libltdl/m4/libtool.m4 (LT_CMD_MAX_LEN): ensure error is
redirected even when getconf does not exist.

--
Chuck
? .signature
Index: libltdl/m4/libtool.m4
===
RCS file: /sources/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.105
diff -u -r1.105 libtool.m4
--- libltdl/m4/libtool.m4   4 Jun 2007 03:01:11 -   1.105
+++ libltdl/m4/libtool.m4   17 Jun 2007 18:23:24 -
@@ -1437,7 +1437,7 @@
 fi
 ;;
   *)
-lt_cv_sys_max_cmd_len=`getconf ARG_MAX 2> /dev/null`
+lt_cv_sys_max_cmd_len=`(getconf ARG_MAX) 2> /dev/null`
 if test -n $lt_cv_sys_max_cmd_len; then
   lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 4`
   lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \* 3`
Index: libtool.m4
===
RCS file: /sources/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.179
diff -u -r1.314.2.179 libtool.m4
--- libtool.m4  4 Jun 2007 03:28:27 -   1.314.2.179
+++ libtool.m4  17 Jun 2007 18:25:33 -
@@ -794,7 +794,7 @@
 fi
 ;;
   *)
-lt_cv_sys_max_cmd_len=`getconf ARG_MAX 2> /dev/null`
+lt_cv_sys_max_cmd_len=`(getconf ARG_MAX) 2> /dev/null`
 if test -n $lt_cv_sys_max_cmd_len; then
   lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 4`
   lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \* 3`


Re: [patch] win32: eliminate wrapper script in main build dir

2007-06-17 Thread Charles Wilson

Ralf Wildenhues wrote:

* Charles Wilson wrote on Sun, Jun 17, 2007 at 02:43:02AM CEST:
Now, in this current patch, we only use _spawnv() if $host == mingw. 
Maybe we could be more clever than that, and only use _spawnv if mingw 
and native.  However, we'd then need to do something about this:


# we should really use a build-platform specific compiler
# here, but OTOH, the wrappers (shell script and this C one)
# are only useful if you want to execute the "real" binary.
# Since the "real" binary is built for $host, then this
# wrapper might as well be built for $host, too.
$opt_dry_run || $LTCC $LTCFLAGS -s -o $cwrapper $cwrappersource


Ah, yes.  Good, looks like your patch doesn't make things worse here.


OK; I'll ignore this issue for now.


The new suite fails tests 25 26 32 54 now, which it
didn't back on 2007-02-24, which is when I last tested it. 
I got those failures (native), until I fixed tests/destdir.at to include 
$EXEEXT on $bindir/m:

[...]

Perhaps that "fix" breaks cross?


No, the failure is earlier: the install command does not find the
programs.  I can "fix" them (make them skip again) by means of the patch
below.  OK?  


OK by me.  Do you wat me to add your patch to mine and check it all in 
at once (e.g. keep the new-testsuite .exe fixes to destdir.at together), 
or will you check your changes in separately?



(Seeing that we need this change, I wonder how many
packages not using Automake (and how many even using Automake) will
break by the new semantics of not having 'prog' but only 'prog.exe'
at least in the cross-compile case...)


Probably a fair many.  However, IMO those packages were improperly 
ported to support (cross-) compiling for mingw anyway: they were relying 
on an internal implementation detail of libtool, in that it happened to 
create a wrapper script with the same full name as the executable 
created by the compiler on 'regular' *nix.



Grepping the verbose output of the old HEAD testsuite for 'No such file
or directory' shows several bits that need adjustment, too.


Well, this is a bit more excusable: INSIDE libtool, we're allowed to 
depend on internal libtool details.  Even if it isn't a really good 
idea, as in this case.


Notwithstanding the answer to my question above concerning 
new-testsuite/destdir.at, I'd appreciate it if you would (at least) 
provide me with your cross-compile verbose log from the old testsuite, 
or (at best) a followup patch to fix these issues -- since I don't have 
a cross-compile setup, here.


In any case, I'd like to postpone the cross-compile old-testsuite .exe 
fixes to a followup patch.


I could use some advice on the following: trying to add a new magic 
string to the executable, I did the obvious (shown after variable 
replacement, etc:


static const char *MAGIC_EXE = "%%%MAGIC EXE variable%%%";

But the compiler stripped the symbol and the initialization string out 
of the executable.


For now just drop the static.  This will work until LTO (link time
optimization) is deployed.  Not sure what we'll need with that in place,
but I suppose either make the variable volatile (another non-fix) or add
a stub volatile access to it in main.


OK. I've already tested that and it does work -- at least at present.

I'll post my current patch in a little while, although I still need to 
test it on (native) mingw, and linux.


--
Chuck




Re: [patch] win32: eliminate wrapper script in main build dir

2007-06-17 Thread Ralf Wildenhues
* Charles Wilson wrote on Sun, Jun 17, 2007 at 02:43:02AM CEST:
> Ralf Wildenhues wrote:
> >
> >Is this code ever to be run on a different system than MinGW?  What
> >about cross-compile setups?  (Maybe you've addressed this in one of
> >the comments of all your patches and I've overlooked it now?)
> 
> In one of the previous patches, we added this bit of support
> 
> +   if test -n "$TARGETSHELL" ; then
> + # no path translation at all
> + lt_newargv0=$TARGETSHELL
> +   else
> + case "$host" in
> +   *mingw* )
> < lots of ugly code to sniff out the 'cmd shell' >
> + ;;
> +   * ) lt_newargv0=$SHELL ;;
> + esac
> +   fi
> 
> for cross-compiling in general (but mainly linux->mingw/wine cross, IIRC).
> 
> Now, in this current patch, we only use _spawnv() if $host == mingw. 
> Maybe we could be more clever than that, and only use _spawnv if mingw 
> and native.  However, we'd then need to do something about this:
> 
> # we should really use a build-platform specific compiler
> # here, but OTOH, the wrappers (shell script and this C one)
> # are only useful if you want to execute the "real" binary.
> # Since the "real" binary is built for $host, then this
> # wrapper might as well be built for $host, too.
> $opt_dry_run || $LTCC $LTCFLAGS -s -o $cwrapper $cwrappersource

Ah, yes.  Good, looks like your patch doesn't make things worse here.

> >The new suite fails tests 25 26 32 54 now, which it
> >didn't back on 2007-02-24, which is when I last tested it. 
> 
> I got those failures (native), until I fixed tests/destdir.at to include 
> $EXEEXT on $bindir/m:
[...]
> Perhaps that "fix" breaks cross?

No, the failure is earlier: the install command does not find the
programs.  I can "fix" them (make them skip again) by means of the patch
below.  OK?  (Seeing that we need this change, I wonder how many
packages not using Automake (and how many even using Automake) will
break by the new semantics of not having 'prog' but only 'prog.exe'
at least in the cross-compile case...)

Grepping the verbose output of the old HEAD testsuite for 'No such file
or directory' shows several bits that need adjustment, too.

> I could use some advice on the following: trying to add a new magic 
> string to the executable, I did the obvious (shown after variable 
> replacement, etc:
> 
> static const char *MAGIC_EXE = "%%%MAGIC EXE variable%%%";
> 
> But the compiler stripped the symbol and the initialization string out 
> of the executable.

For now just drop the static.  This will work until LTO (link time
optimization) is deployed.  Not sure what we'll need with that in place,
but I suppose either make the variable volatile (another non-fix) or add
a stub volatile access to it in main.

Cheers,
Ralf

Index: tests/destdir.at
===
RCS file: /cvsroot/libtool/libtool/tests/destdir.at,v
retrieving revision 1.5
diff -u -r1.5 destdir.at
--- tests/destdir.at25 Mar 2007 12:12:43 -  1.5
+++ tests/destdir.at17 Jun 2007 08:09:50 -
@@ -60,7 +60,7 @@
 mkdir $DESTDIR$libdir $DESTDIR$bindir
 AT_CHECK([$LIBTOOL --mode=install cp liba.la $DESTDIR$libdir/liba.la],
 [], [ignore], [ignore])
-AT_CHECK([$LIBTOOL --mode=install cp m $DESTDIR$bindir/m],
+AT_CHECK([$LIBTOOL --mode=install cp m$EXEEXT $DESTDIR$bindir/m$EXEEXT],
 [], [ignore], [ignore])
 $LIBTOOL --mode=clean rm -f liba.la m
 LT_AT_MVDIR(["$DESTDIR$libdir"], ["$libdir"])
@@ -99,7 +99,7 @@
 [], [ignore], [ignore])
 AT_CHECK([$LIBTOOL --mode=install cp liba.la $DESTDIR$libdir/liba.la],
 [], [ignore], [ignore])
-AT_CHECK([$LIBTOOL --mode=install cp m $DESTDIR$bindir/m],
+AT_CHECK([$LIBTOOL --mode=install cp m$EXEEXT $DESTDIR$bindir/m$EXEEXT],
 [], [ignore], [ignore])
 $LIBTOOL --mode=clean rm -f liba1dep.la liba2dep.la liba.la m
 LT_AT_MVDIR(["$DESTDIR$libdir"], ["$libdir"])




Re: distchecking without FC?

2007-06-17 Thread Noah Misch
Hi Ralf,

On Sat, Jun 16, 2007 at 11:13:36AM +0200, Ralf Wildenhues wrote:
> * Noah Misch wrote on Fri, Jun 15, 2007 at 02:42:04AM CEST:
> > Therefore, I took a different approach:
> > list the files to distribute directly in the top-level Makefile.am,
> > and do not bother to configure the test directories for `make dist'.
> 
> This would break down at the point when Autoconf or Automake decide to
> generate a different set of files (and we try to support both older and
> newer version).  Arguably this doesn't happen too often, and Stepan has
> too little time to carry out his plans...

True.

> > If better, we could compromise between complexity
> > and redundancy by generating the list of files at `bootstrap' time.
> 
> If you've already tried this, please post the patch.  Thanks.
> Otherwise I suppose we can cross the bridge when we come to it
> (you could put a FIXME above the list).

Not yet, sorry.  I can look into it.

> > In any case, `make dist' runs an order magnitude faster.
> 
> FWIW, I could care less about `dist' time.  `check' and `all' are much
> more interesting.

Certainly; this speed improvement is but a minor bonus.

> > While examining this, I tried `make distcheck'.  It failed due to a
> > `config.log' left in tests/fcdemo when its `configure' fails.  This
> > patch incorporates a two-line fix to avoid that problem.
> 
> This is fine.
> 
> It seems the others like this patch, so I won't stand in the way.  ;-)

Thanks.  Now if only I can entice someone to install it.

Thanks,
Noah