Re: autoconf and OS/2

[Andreas Buening]

Paul Eggert wrote:
> 
> > From: Andreas Buening <address@hidden>
> > Date: Thu, 27 Sep 2001 21:45:50 +0200
> >
> > 1) The included mkinstalldirs doesn't work if the directory
> >    name contains a drive letter, e.g. mkinstalldirs x:/dir.
> >    The reason is the following code line which is used twice
> >    in mkinstalldirs:
> >
> >    if test ! -d "$pathcomp"; then
> >
> >    This doesn't work if $pathcomp is a drive letter
> >    because "x:" is no directory. ("cp foo x:" e.g. will
> >    copy "foo" to the current directory of x: whatever this
> >    may be for the current process).
> 
> Hmm, then why isn't "x:" a directory?  This seems to me to be a bug in
> "test" on your platform.  If "x:" evaluates to the working directory
> of drive x, then "test -d x:" ought to succeed.

That would have some really bad side effects:

if test -d "$dest_dir"; then
  cp my_file "$dest_dir"
fi

If x: is assumed to be a directory my_file would be copied somewhere.


> However, this point may be moot now that mkinstalldirs uses mkdir -p.
> If mkdir -p works on your platform, the test ! -d stuff will never be
> executed, and so it's not worth worrying about.  See:
> http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/automake/lib/mkinstalldirs?rev=1.8&content-type=text/plain&cvsroot=automake

mkdir -p works. However, I wonder why not using ginstall -d instead of
mkinstalldirs?


> > +# Note: x: is also treated as an absolute path, so --prefix=x: is
> > allowed.
> 
> I don't understand this point.  "x:" is a relative path, just as "x:y"
> is.  Which directory "x:" stands for depends on the runtime context.
> So "x:" shouldn't be treated as absolute, any more than "x:y" or "y"
> should be treated as absolute.

May be. At least it works because all files are installed into
$prefix/... which is a absolute path because of the first '/'.


[snip]

> > 4) Backslashes in $PATH do not work,
> 
> There are many, many places where backslashes in $PATH will not work.
> Not to mention commas, newlines, or probably several other characters.
> In theory it would be nice to allow arbitrary characters in $PATH; but
> in practice, it's probably better to document the current restrictions,
> as there are more pressing things to worry about.

configure could change '\' into '/'. This isn't that difficult.


bye,
Andreas