[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: autoconf and OS/2

From: Akim Demaille
Subject: Re: autoconf and OS/2
Date: 27 Sep 2001 13:37:56 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Artificial Intelligence)

| On 19 Jun 2001 05:20:09 -0300, Alexandre Oliva wrote:
| > On Jun 18, 2001, Akim Demaille <address@hidden> wrote:
| > 
| > >   # Make a symlink if possible; otherwise try a hard link.
| > >   ln -s $ac_rel_source $ac_dest 2>/dev/null ||
| > >     ln $srcdir/$ac_source $ac_dest ||
| > >     AC_MSG_ERROR([cannot link $ac_dest to $srcdir/$ac_source])
| > 
| > > Now, the question is why we never used `cp -p' here.
| > 
| > I think the answer is that we had never ported autoconf to a platform
| > in which neither ln -s nor ln would work.  Cygwin, for example,
| > implements ln as cp.  I don't see a reason to not add `cp -p',
| > though, except a little bit of concern about portability of -p.
| Well, cp -p is already used by the check for as_ln_s, so I'm not sure
| that's much of a concern.
| I would like to point out that it is probably a good idea to use
| $as_ln_s here in order not to run into more subtle failures.  For
| example, on DJGPP, ln -s will create an executable stub (ln -s foo bar
| creates bar.exe, which, when run, will try to run "foo").  This breaks
| the current command, but is tested (and avoided) when deducing as_ln_s.
| So using
|   if $as_ln_s = "ln -s"; then
|     ln -s <ln -s style options> || error
|   else
|     $as_ln_s <ln/cp style options> || error
|   fi
| would be better IMHO.  Any portability concerns for ln/cp could then
| be moved to the as_ln_s check instead of having to worry about
| propagating them to places where a bare ln -s is used.

Tim, would you write a AS_LN_S please?  Please, pay attention to the
very special semantics of ln -s some/path an/other.  See
AC_OUTPUT_LINKS for what must be done.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]