Re: autoconf and OS/2

[Tim Van Holder]

> What do you think a "clean, portable way" could be?
> Using "which"? The sh builtin "type"? The most general idea I can
> imagine
> is to search the whole path for "foo" and "foo.*" and to try to execute
> every file that is found. If "test foo.blurb" is true then ".blurb" must
> be an executable extension (or at least a very strange filename ;-) )
> What else? Using a system() call? Not every configure script needs
> a C compiler. The executable extensions may depend from the used shell
> ...

All very true, and precisely the reasons this functionality is not yet
in autoconf :-).
'which' actually isn't portable (if it was, the current path searching
wouldn't be needed), and all the other methods tend to be either
unportable or prone to error.
A fairly clean way would be to let the list depend on $host (since
only a small amount of systems use executable extensions, this could a
fairly small case statement); but this would violate the autoconf motto
'test for a feature, not a system'.

> Another possibility would be to introduce a new configure option
> --enable-extensions=exe,com,cmd.

I suppose, but that's basically what I do now through config.site,
except that options need to get passed each run, while config.site
only needs to be set up once (in my case, I build the DJGPP package
for autoconf, and I distribute a config.site that looks for .exe and
.bat files).

> [(back)slash discussion]
>
> > You could try doing
> >
> >   PATH=`echo "$PATH" | tr '\\' '/'`
> >
> > in your config.site; that may break if configure needs to run
> applications
> > that expect PATH to use backslashes.
>
> Sorry, what is "config.site"?

configure sources a file called "$prefix/config.site" on startup.
You can use that to set environment variables that help configure
scripts run better.  For example, this is the config.site used for
the DJGPP package

== start of file
# NOTE: for optimal functionality, you should NOT have TEST_FINDS_EXE set,
# and PATH_SEPARATOR should either be unset, or set to ';'.

# Feel free to add others (.com, .btm, .sh, .pl, ...) to this list if you
# need configure scripts to find such files.  Try to limit it to things
# you need to avoid false positives.
ac_executable_extensions=".exe .bat"

# Uncomment these to avoid typical portability problems
#ac_cv_func_fork=no
#ac_cv_func_mkfifo=no
#ac_cv_func_mknod=no
#ac_cv_func_mmap=no
#ac_cv_func_pipe=no
#ac_cv_func_vfork=no

# By using this, results of configure's program checks will be more portable
PATH="/dev/env/DJDIR/bin;$PATH"

# This is REQUIRED: using simply "/bin/(ba)sh" will NOT work (m4 needs this
# to be a full path with executable suffix)
SHELL=/dev/env/DJDIR/bin/bash.exe
CONFIG_SHELL=$SHELL
== end of file

If you set PATH in config.site, it will automatically take effect in any
configure script you run.

> Perhaps you could mention in INSTALL that ';' but no '\\' is supported
> for $PATH.

Perhaps, yes.  Could you investigate exactly where it goes wrong?  It
might be easy to fix.  I've already tried to support DOS paths wherever
possible (at some point I even plan to tackle AS_DIRNAME :-) ), so I'm
interested in getting this fairly essential macro to work.

> [acgeneral.m4]
>
> >    # Make a symlink if possible; otherwise try a hard link.
> > -  ln -s $ac_rel_source $ac_dest 2>/dev/null ||
> > +  if test "$as_ln_s" = "ln -s"; then
> > +    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])
> > +  else
> >      ln $srcdir/$ac_source $ac_dest ||
> > -    AC_MSG_ERROR([cannot link $ac_dest to $srcdir/$ac_source])
> > +      AC_MSG_ERROR([cannot link $ac_dest to $srcdir/$ac_source])
> > +  fi
> >  m4_ifset([AC_LIST_LINKS_COMMANDS],
> >  [  # Run the commands associated with the file.
> >    case $ac_file in
>
> Why do you use AC_MSG_ERROR? I suggested to use cp -p if "ln" was unable
> to create a link and to print a warning. OS/2 has no working ln. Even

You mean the OS/2 port of fileutils has no ln?  It definitely should - if
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.

> if there were one it wouldn't be able to create a link.
> Using cp -p wouldn't have any side effects on other systems and
> make distclean should also remove this special file.
> (Additionally as_ln_s is set to "cp -p" by default if ln doesn't work)

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.

But I suppose

if test "$as_ln_s" = "ln -s"; then
  ln -s $ac_rel_source $ac_dest 2>/dev/null ||
    AC_MSG_ERROR([cannot link $ac_dest to $ac_rel_source])
else
  $as_ln_s $srcdir/$ac_source $ac_dest ||
    AC_MSG_ERROR([cannot link $ac_dest to $srcdir/$ac_source])
fi

would be best - that'll use 'ln' or 'cp -p', whatever works.

Akim, your thoughts?