autoconf-patches
[Top][All Lists]
Advanced

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

Re: autoconf and OS/2


From: Tim Van Holder
Subject: Re: autoconf and OS/2
Date: Tue, 19 Jun 2001 19:28:14 +0200

> In my opinion a additional configure option would be the best solution
> (or a documented environment variable if you like). Why? It doesn't

Well, config.site is merely a way to set such documented evironment
variables (and undocumented ones as well); with the
ac_executable_extensions patch, you could simply do

set ac_executable_extensions=".exe .bat .cmd"
sh configure

and it would work (without relying on --prefix).

Also, config.site is not necessarily used from $prefix/share.  You could
have an appropriate config.site in an os2 subdir of an OS/2 source
package; then include a config.bat that does:

  set CONFIG_SITE=os2/config.site
  sh configure

and configure will source os2/config.site (you may need to factor
srcdir in there somewhere).

> In acgeneral.m4:
> There is a macro _AC_INIT_PREPARE_FS_SEPARATORS that sets
> ac_path_separator.
> This might be the right place to determine the (back)slash to be used.

Yes, but
  a) most systems that use \ also support / (DJGPP, Cygwin)
  b) checking \ requires quoting the \ properly, which is harder
     if it's in a variable that might just have a / - so [\\/] is used
     wherever it's needed.  This is not optimal (a Unix path with an
     embedded backslash won't work properly), but it's probably the best
     we can do.  I will try to look into the PATH issue at some point in
     the near future, but I would recommend using a config.site and
     massaging $PATH there yourself.

> > it doesn't, file a bug report with the maintainers of the OS/2 port. If
it
> > does, the correct behaviour would be for plain ln (ie no -s) to act as a
> > copy; and that is what I rely on.
>
> Why should it? If you have a file system that definitly doesn't support
> links ln will and must fail in my opinion.

Why should it?  Well, exactly because it avoids portability issues like the
one's you're experiencing.  The three other environments that deal with
pretty much the same environment as OS/2 (DJGPP, Cygwin, mingw32) all
have an ln that acts like a copy (only ln -s behaviour differs somewhat).

> > I originally suggested simply using $as_ln_s here, as it is deduced at
> > startup anyway - the problem is that cp and ln have different behaviour
> > when passed relative paths.
>
> In what way? Do you have an example?
easy:

> >   ln -s $ac_rel_source $ac_dest 2>/dev/null ||

> >   $as_ln_s $srcdir/$ac_source $ac_dest ||

These are intended to be equivalent, but use different parameters.

ln -s ../foo bar/baz creates a broken link (the bar/baz link would
point to bar/../foo); making arguments to ln -s absolute results
in different behaviour, which is why relative paths are passed.
(At least this is how I understand it)




reply via email to

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