Re: [Emacs-diffs] master 2534676 2/2: Simplify setfattr use by assuming GNU make
On 01/02/2015 11:12 AM, Glenn Morris wrote:
The autoconf manual says Don't rely on ln having a -f option.
Although that was good advice in the early 1990s when that part of the
Autoconf manual was written, the advice has been obsolete for years. I
installed the attached patch into Autoconf to fix this (after bumping
Autoconf's copyright year). I'm CC:ing this to autoconf-patches.
From 4774ff5c33d34bb6ad21c06f3c2b54d6e700740e Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Fri, 2 Jan 2015 13:02:48 -0800
Subject: [PATCH] doc: -f is now portable for cp and ln
This follows up on a comment by Glenn Morris in:
http://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00011.html
* doc/autoconf.texi (Limitations of Usual Tools):
Remove circa-1990 advice about avoiding cp -f and ln -f.
Although that advice was reasonable for the early 1990s, the -f
option is portable for both cp and ln nowadays. These options
were standardized in POSIX 1003.2-1992, and pre-POSIX systems such
as SunOS 4 are no longer of practical concern.
---
doc/autoconf.texi | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 639cec2..d9e833d 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -18684,9 +18684,7 @@ avoid this problem, omit the trailing slashes. For example, use
@samp{cp -R source /tmp/newdir} rather than @samp{cp -R source
/tmp/newdir/} if @file{/tmp/newdir} does not exist.
-@c This is thanks to Ian.
-The ancient SunOS 4 @command{cp} does not support @option{-f}, although
-its @command{mv} does.
+The @option{-f} option is portable nowadays.
@cindex timestamp resolution
Traditionally, file timestamps had 1-second resolution, and @samp{cp
@@ -19088,9 +19086,11 @@ the workaround is to use @command{join -a1 file1 file2} instead.
@item @command{ln}
@c ---
@prindex @command{ln}
+The @option{-f} option is portable nowadays.
+
@cindex Symbolic links
-Don't rely on @command{ln} having a @option{-f} option. Symbolic links
-are not available on old systems; use @samp{$(LN_S)} as a portable substitute.
+Symbolic links are not available on some systems; use @samp{$(LN_S)} as
+a portable substitute.
For versions of the DJGPP before 2.04,
@command{ln} emulates symbolic links
--
2.1.0
Re: Mangled argument vector choking on spaces?
On Fri, 2015-01-02 at 16:06 -0700, Eric Blake wrote: While paths with spaces in them may be a fact of reality, they are non-portable according to POSIX. It is going to be an uphill battle if you want to submit patches to make autoconf automatically handle file names with spaces, as there is nothing portable about them. We all agree they're not portable. We also all agree autoconf is intended to generate portable configure scripts. If this were ever patched, it would probably involve some clever way of distinguishing spaces in paths from argument separators in the argument vector. The only way I can see this ever happening is if argument vectors were prepared through higher level functions, such as M4 macros, with different functions to distinguish the two semantics. -- Kip Warner -- Senior Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com signature.asc Description: This is a digitally signed message part ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Mangled argument vector choking on spaces?
On 01/01/2015 02:57 PM, Kip Warner wrote: On Wed, 2014-12-31 at 12:02 -0500, David A. Wheeler wrote: They can do workarounds with symlinks, etc., to try to *hide* the reality, but since autoconf is supposed to do things *automatically*, that means that autoconf fails to do the one job it's supposed to do: automatic configuration. Agreed. The whole purpose of autoconf is to help write portable scripts. Paths with spaces in them, whether we like them or not, is often uncontrollable and a fact of reality. While paths with spaces in them may be a fact of reality, they are non-portable according to POSIX. It is going to be an uphill battle if you want to submit patches to make autoconf automatically handle file names with spaces, as there is nothing portable about them. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Mangled argument vector choking on spaces?
On Fri, 2 Jan 2015, Eric Blake wrote: While paths with spaces in them may be a fact of reality, they are non-portable according to POSIX. It is going to be an uphill battle if you want to submit patches to make autoconf automatically handle file names with spaces, as there is nothing portable about them. Even if Automake, Autoconf, libtool, intrinsics can be proven to work with spaces, many significant build environments would still fail. This is because autotools provide just part of the build configuration. The project developer adds the rest. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
