FYI: fix bogus merge (Libtool HEAD)

2005-07-11 Thread Ralf Wildenhues
Hi Patrick,

Regarding your recent problem report[1] with a m4 loop in CVS autotools:
While I can reproduce it over here, I have not found its cause yet.

But it turned up another bug in Libtool CVS HEAD, presumably caused by
a bogus CVS merge.  Checked in the patch below as obvious.  (This bug
shows up only if you do `sinclude(libtool.m4)', not if aclocal pulls in
the macros.)

Cheers,
Ralf

[1] http://lists.gnu.org/archive/html/libtool/2005-07/msg00023.html

2005-07-11  Ralf Wildenhues  [EMAIL PROTECTED]

* m4/libtool.m4 (_LT_CHECK_XSI_SHELL): Fix bogus merge.
Reported by Patrick Welche [EMAIL PROTECTED].

Index: m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/m4/libtool.m4,v
retrieving revision 1.202
diff -u -r1.202 libtool.m4
--- m4/libtool.m4   8 Jul 2005 14:59:59 -   1.202
+++ m4/libtool.m4   11 Jul 2005 12:04:53 -
@@ -6213,8 +6213,6 @@
   = c,a/b,, ) /dev/null 21 \
xsi_shell=yes
 AC_MSG_RESULT([$xsi_shell])
-])
-fi
 _LT_CONFIG_LIBTOOL_INIT([xsi_shell='$xsi_shell'])
 ])# _LT_CHECK_XSI_SHELL
 




RE: MSYS+MSVC for libtool branch-2-0, take 2

2005-07-11 Thread Bob Friesenhahn

On Mon, 11 Jul 2005, Peter Ekberg wrote:

You don't seem to understand what's going on... On MSYS there
is no official way to convert a posix path to a win32 path
(like cygpath on Cygwin). But if you execute any executable
outside of the MSYS /bin or /usr/bin directories (and perhaps
other places as well?), any argument that looks like a posix
path is converted to a win32 path on the assumption that all
such executables expect win32 paths. The problem is that in
this case the conversion needs to be done not on an argument,
but on an environment variable that MSYS does not autoconvert.
So, it needs to be converted manually. So, since there is no
official way to convert paths, I run a program outside of MSYS
and as one of its arguments I have the posix path to be
converted. The program I have chosen to run is the command


This is the script I run under MSYS or Cygwin to convert a POSIX path 
to a win32 paths with varying amount of escaping in case the result 
needs to be handled by a script later.  It has been pointed out to me 
that Windows converts forward slashes to backslashes so it is not 
necessary to generate backslashes, but paths are often seen by Windows 
users so I try to generate paths which are familiar to them.


#!/bin/sh
# Copyright (C) 2003 GraphicsMagick Group
#
# This program is covered by multiple licenses, which are described in
# Copyright.txt. You should have received a copy of Copyright.txt with this
# package; otherwise see http://www.graphicsmagick.org/www/Copyright.html.
#
# Convert the specified POSIX path to a Windows path under MinGW and Cygwin
# The optional second parameter specifies the level of backslash escaping
# to apply for each Windows backslash position in order to support varying
# levels of variable substitutions in scripts.
#
# Note that Cygwin includes the 'cygpath' utility, which already provides
# path translation capability.
#
# Written by Bob Friesenhahn [EMAIL PROTECTED] June 2002
#
arg=$1
escapes=0
if test -n $2
then
  escapes=$2
fi
if test $escapes -gt 3
then
  echo $0: escape level must in range 0 - 3
  exit 1
fi
result=''
length=0
max_length=0
mount | sed -e 's:\\:/:g'  | (
  IFS=\n
  while read mount_entry
  do
win_mount_path=`echo $mount_entry | sed -e 's: .*::g'`
unix_mount_path=`echo $mount_entry | sed -e 's:.* on ::;s: type .*::'`
temp=`echo $arg | sed -e s!^$unix_mount_path!$win_mount_path!`
if test $temp != $arg
then
  candidate=$temp
  length=${#unix_mount_path}
  if test $length -gt $max_length
  then
result=$candidate
max_length=$length
  fi
fi
  done
  if test -z $result
  then
echo $0: path \$arg\ is not mounted
exit 1
  fi
  case $escapes in
0)
 echo $result | sed -e 's:/:\\:g'
 ;;
1)
 echo $result | sed -e 's:/::g'
 ;;
2)
 echo $result | sed -e 's:/::g'
 ;;
3)
 echo $result | sed -e 's:/::g'
 ;;
  esac
  exit 0;
 )

==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/




RE: MSYS+MSVC for libtool branch-2-0, take 2

2005-07-11 Thread Bob Friesenhahn

On Mon, 11 Jul 2005, Peter Ekberg wrote:


Yes, I came across that one, but it seemed heavy handed for the
job at hand. I think my approach is neater, but I'm biased :-)
In what way is your script better than my version that simply
uses the cmd script from MSYS?


I am not sure that my script is better.  It just happens to work 
identically across MSYS and Cygwin without using tools peculiar to 
either environment.  All it needs is 'mount' and 'sed'.



Neither approach has a chance to work in a cross compile setup,
which was the objection to my approach...


Quite true.  Cross compile needs special care.

It is quite rare for Windows executables to include hard-coded paths. 
This is much more common for Unix.  So Unix software which is quickly 
ported to Windows may need to include some hard-coded paths.  Windows 
software doesn't have any notion of an installation prefix except 
for at software install time.


Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/