Autoconf problem with drive letters in file names

Autoconf-generated configure scripts usually include the following snippet: ac_file_inputs=`echo $ac_file_in | \ sed -e "s%^%$ac_given_srcdir/%" -e "s%:% $ac_given_srcdir/%g"` (This is one long line; I've split it for readability and to prevent it from being munged by mailers.) This ma

Re: Need help with Windows port for GNU make (+ DOS pretesters)

> Date: Tue, 9 May 2000 10:18:19 -0400 (EDT) > From: "Paul D. Smith" <[EMAIL PROTECTED]> > > BTW, while Eli Zaretskii is still providing excellent support for the > DOS port of GNU make, it would be great if we had a few more pretesters > for this port, as w

Re: Detecting DJGPP, Cygwin, Mingwin and EMX OS/2

On 24 May 2000, Akim Demaille wrote: > Currently to find out if we are under one of these environments > configure runs a compilation, typically to see if __CYGWIN__ is > defined etc. > > Can't we do this kind of checks *without* compiling? For DJGPP, you can look for the variable DJDIR in the

Re: Detecting DJGPP, Cygwin, Mingwin and EMX OS/2

On Wed, 24 May 2000, Earnie Boyd wrote: > Cygwin comes with uname which reports: > CYGWIN_NT-4.0 DU147636 1.1.0(0.17/3/2) 2000-03-01 00:15:19 i686 unknown > > For MinGW I have a uname hack which reports: > MINGW_WinNT DU147636 3 0 i686 unknown Sounds a bit dangerous to me: what if someone uses

Re: Detecting DJGPP, Cygwin, Mingwin and EMX OS/2

On 24 May 2000, Alexandre Oliva wrote: > How about something like (totally untested): > > if (cd c:\\ && cd .. && test `pwd` = "C:\\") 2> /dev/null This should work with any DOS/Windows environment, it's not specific to any of the three (DJGPP, Mingw, or Cygwin). So it cannot reliably disti

Re: Detecting DJGPP, Cygwin, Mingwin and EMX OS/2

On Wed, 24 May 2000, Earnie Boyd wrote: > > > Cygwin comes with uname which reports: > > > CYGWIN_NT-4.0 DU147636 1.1.0(0.17/3/2) 2000-03-01 00:15:19 i686 unknown > > > > > > For MinGW I have a uname hack which reports: > > > MINGW_WinNT DU147636 3 0 i686 unknown > > > > Sounds a bit dangerous

Re: [patch] acgeneral.m4 (dirname usage)

> From: Akim Demaille <[EMAIL PROTECTED]> > Date: 06 Jul 2000 17:03:52 +0200 > > Foreignward compatibility is indeed desired. But are you sure we're > losing here? Mark, or Eli, what do you think we should do? We're > trying to implement dirname. `al' is the current CVS solution. Sorry, I don

Re: [patch] acgeneral.m4 (dirname usage)

> From: Alexandre Oliva <[EMAIL PROTECTED]> > Date: 06 Jul 2000 12:30:15 -0300 > > What does `dirname' do, on those platforms, when given such special > pathnames? I'm guessing that you are now talking about `dirname' from Bash or from Sh-utils, yes? If so, then it does pretty much the same thi

Re: portability of sed's \{0,1\}?

> Date: Fri, 11 Aug 2000 12:56:20 -0700 (PDT) > From: Paul Eggert <[EMAIL PROTECTED]> > > Most likely, seds that don't support ? and \| also don't support > \{m,n\}, as I recall that those features were introduced to USG Unix > at about the same time. My references indicate otherwise. For examp

Re: portability of sed's \{0,1\}?

> Date: Fri, 11 Aug 2000 12:56:20 -0700 (PDT) > From: Paul Eggert <[EMAIL PROTECTED]> > > Most likely, seds that don't support ? and \| also don't support > \{m,n\}, as I recall that those features were introduced to USG Unix > at about the same time. My references indicate otherwise. For examp

depcomp and DOS-style file names with drive letters

. The patch to depcomp which fixes this is below. It assumes that \{m,n\} is supported by all versions of Sed. 2000-08-11 Eli Zaretskii <[EMAIL PROTECTED]> * depcomp (gcc): Support DOS-style absolute file names with drive letters. --- depcomp.~0 Mon Oct 4 07:56:46 1999 +++

Re: depcomp and DOS-style file names with drive letters

> From: Jim Meyering <[EMAIL PROTECTED]> > Date: 12 Aug 2000 12:21:27 +0200 > > | - sed 's/^[^:]*: / /' < "$tmpdepfile" >> "$depfile" > | + sed 's/^\([A-Za-z]:\/\)\{0,1\}[^:]*: / /' < "$tmpdepfile" >> "$depfile" > | ## This next piece of magic avoids the `deleted header file' problem. > | ## T

Re: portability of sed's \{0,1\}?

On Sat, 12 Aug 2000, Paul Eggert wrote: > The sed FAQ, version 014 says: > > * Ultrix 4.3 sed doesn't support \(...\)\{...\} (the idiom used here). > * Likewise for HHsed v1.5 (by Howard Helman). > * sedmod v1.0 (by Hern Chen) doesn't support \{..

Re: portability of sed's \{0,1\}?

> Date: Sun, 13 Aug 2000 14:51:06 -0700 (PDT) > From: Paul Eggert <[EMAIL PROTECTED]> > >I don't see any work-arounds suggested for these problems. >Does anyone know how do you express \(foo\)\{0,1\} portably? > > There's no simple, general substitute for \(foo\)\{0,1\}, but you can > ge

Re: portability of sed's \{0,1\}?

> From: Jim Meyering <[EMAIL PROTECTED]> > Date: 11 Aug 2000 20:11:25 +0200 > > "Eli Zaretskii" <[EMAIL PROTECTED]> writes: > | > | Also, is \{0,1\} supported in all versions of > | > | Sed? > | > > | > I'm almost positive that

Re: Autoconf 2.52g is released

> From: Akim Demaille <[EMAIL PROTECTED]> > Newsgroups: gnu.utils.bug > Date: 25 Jan 2002 12:48:15 +0100 > > We aim at releasing 2.53 within the next months. This is also a call > for people ready to: > > - improve the documentation > - upgrade existing specific macros > - import into Autoconf

Re: Autoconf 2.52g is released

On Sun, 27 Jan 2002, Thomas Dickey wrote: > "cp -p" has some unfortunate side-effects (some versions copy the ownership > of the original file in addition to the protection) Why is that bad? Those files are typically header files that the compiler needs to compile the program. If we can live

Re: Autoconf 2.52g is released

On Sun, 27 Jan 2002, Thomas Dickey wrote: > I had in mind that someone's likely to try to use the same script for > installing files that use symbolic links. Ah, I see. Thanks for explaining this.

How does Autoconf produce PACKAGE_URL?

Hi, As you may or may not know, building Gawk on non-Posix systems uses files in the pc/ subdirectory, which includes manually maintained Makefile and config.h files. For the next release of Gawk, I wrote a script to produce the pc/config.h file from the configh.in template used by the configure

Re: How does Autoconf produce PACKAGE_URL?

> Date: Sun, 30 Oct 2011 00:00:43 +0200 > From: Hans Ulrich Niedermann > > On 29/10/11 18:38, Eli Zaretskii wrote: > > However, there's one macro in config.h for whose value I didn't find > > the source in any non-generated file: PACKAGE_URL. I can only see i

Re: POSIX ruling on up-to-date vs. identical timestamps

> From: Paul Smith > Date: Tue, 26 Aug 2014 10:52:32 -0400 > Cc: Autoconf , Eric Blake , > bug-make > > Of course the ability to track filesystems could be added without too > much effort. It's trivial to determine the filesystem in POSIX via the > device ID available from stat(), of cour

Re: POSIX ruling on up-to-date vs. identical timestamps

> From: Paul Smith > Cc: egg...@cs.ucla.edu, Autoconf@gnu.org, ebl...@redhat.com, bug-m...@gnu.org > Date: Tue, 26 Aug 2014 11:18:35 -0400 > > > The main problem is that this requires to write a replacement 'stat' > > (not rocket science). > > Can't we just #define stat(_p,_b) _stat(_p,_b)? Not

Re: POSIX ruling on up-to-date vs. identical timestamps

> Date: Tue, 26 Aug 2014 08:25:38 -0700 > From: Paul Eggert > Cc: Autoconf , Eric Blake , > bug-make > > As far as Windows goes, NTFS file systems have 100 ns resolution, and > FAT file systems are the joker as they have a 2-second resolution for > last-modified time. That's true, but F

Re: POSIX ruling on up-to-date vs. identical timestamps

> Date: Tue, 26 Aug 2014 18:30:12 +0100 > From: Keith Marshall > CC: Autoconf@gnu.org, ebl...@redhat.com, bug-m...@gnu.org > > > FAT filesystems are hardly important these days. > > Except insofar as they tend to be prevalent on removable media devices, > such as USB flash drives; woe betide any

Re: Fw: bug in texi2dvi, and hack patch

> Date: Wed, 19 Jan 2005 05:36:26 -0700 > From: Eric Blake <[EMAIL PROTECTED]> > CC: bug-texinfo@gnu.org, autoconf@gnu.org > > > If this is what Autoconf 2.59 really does (i.e., no typos etc. in this > > snippet), then Autoconf 2.59 is broken, at least for DJGPP, because it > > will always produc

Re: Fw: bug in texi2dvi, and hack patch

> Date: Thu, 20 Jan 2005 12:35:08 +0100 > From: Stepan Kasal <[EMAIL PROTECTED]> > Cc: Eric Blake <[EMAIL PROTECTED]>, autoconf@gnu.org, bug-texinfo@gnu.org > > The trick is that AC_CHECK_PROG contains the following code: > > for ac_exec_ext in '' $ac_executable_extensions; do > if AS_EXECUTABL

Re: Fw: bug in texi2dvi, and hack patch

> From: Ben Pfaff <[EMAIL PROTECTED]> > Date: Thu, 20 Jan 2005 13:30:27 -0800 > Cc: autoconf@gnu.org > > >>test -f tex.exe && test -x tex.exe > > > > This will work, but is redundant: it's enough to test for tex.exe, > > since it's always executable on MS systems. > > I have had Windows syste

Re: Fw: bug in texi2dvi, and hack patch

> Cc: bug-texinfo@gnu.org, autoconf@gnu.org > From: Ben Pfaff <[EMAIL PROTECTED]> > Date: Fri, 21 Jan 2005 08:58:39 -0800 > > >> I have had Windows systems refuse to execute .exe files that were > >> mounted off a NetApp until I switched over to a Unix system and > >> did a chmod +x. > > > > This

Re: AS_EXECUTABLE_P again -- summary (was: bug in texi2dvi, and hack patch)

> Date: Sat, 22 Jan 2005 16:30:07 +0100 > From: Stepan Kasal <[EMAIL PROTECTED]> > Cc: Eric Blake <[EMAIL PROTECTED]>, autoconf@gnu.org, bug-texinfo@gnu.org > > I proposed to change the implementation of AS_EXECUTABLE_P on platforms > supporting `test -x' from >test -f $1 && test -x $1 > t

Re: AS_EXECUTABLE_P again -- summary (was: bug in texi2dvi, and hack patch)

> Date: Sat, 22 Jan 2005 17:57:44 +0100 > From: Stepan Kasal <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], autoconf@gnu.org, bug-texinfo@gnu.org > > If there was a named pipe /tmp/foo with an executable bit set, the test > could misclasify it as an executable file. Thanks for the explanations. FW

Re: AS_EXECUTABLE_P again -- summary

> Date: Sat, 22 Jan 2005 19:51:06 -0700 > From: Eric Blake <[EMAIL PROTECTED]> > CC: Stepan Kasal <[EMAIL PROTECTED]>, autoconf@gnu.org, bug-texinfo@gnu.org > > >>2) On Cygwin, both `test -x foo' and `test -f foo' look for foo.exe. > > > > That's a bug, IMHO. > > It's actually a design decisio

Re: AC_PROG_CC_C_O doesn't work with VC++

> Date: Tue, 25 Oct 2005 14:26:23 +0200 > From: Stepan Kasal <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > > > Microsoft added long file name support in Win95 -- the first of the 32-bit > > Windoze releases. The requirement to support 8.3 file names disappeared > > with the demise of MS-DOS, arou

Re: AC_PROG_CC_C_O doesn't work with VC++

> Date: Tue, 25 Oct 2005 10:25:25 -0500 (CDT) > From: Bob Friesenhahn <[EMAIL PROTECTED]> > cc: autoconf@gnu.org > > Perhaps MS-DOS will never die, but the requirement to actually build > software under MS-DOS is gone because MS-DOS cross-development tools > are available which run on more capab

Re: AC_PROG_CC_C_O doesn't work with VC++

> Cc: autoconf@gnu.org, > [EMAIL PROTECTED], > autoconf-patches@gnu.org > From: Keith MARSHALL <[EMAIL PROTECTED]> > Date: Tue, 25 Oct 2005 16:29:13 +0100 > > Regarding DJGPP, is the modern version still bound by 8.3 file name > constraints? When DJGPP programs run on Windows 95 and l

Re: AC_PROG_CC_C_O doesn't work with VC++

> Date: Wed, 26 Oct 2005 08:17:52 +0200 > From: Stepan Kasal <[EMAIL PROTECTED]> > Cc: autoconf@gnu.org, autoconf-patches@gnu.org > > the problem is this: ./configure runs > $CC -c -o conftst2.$ac_objext conftest.c > and then checks whether the compiler created conftst2.$ac_objext or > conft

Re: emacs-22.0.99 configure problem

> From: Paul Eggert <[EMAIL PROTECTED]> > Date: Tue, 01 May 2007 19:37:34 -0700 > Cc: [EMAIL PROTECTED], autoconf@gnu.org, [EMAIL PROTECTED] > > Perhaps the simplest thing is to generate a new Autoconf version? You > could then install and use that. It should not take much time for me > to gener

Re: Autoconf 2.52g is released

On 13 Mar 2002, Akim Demaille wrote: > I hope you don't mind my using this text into the Autoconf doc? No, I don't mind.