autoconf-patches
[Top][All Lists]
Advanced

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

Re: autoconf and OS/2


From: Andreas Buening
Subject: Re: autoconf and OS/2
Date: Fri, 15 Jun 2001 21:59:26 +0200

Tim Van Holder wrote:
> 
> > 1) *.exe files weren't found in $PATH
> 
> A known issue - the problem is that testing for .exe is not
> enough; we'd also want to find .bat, .com, etc.
> 
> Below is a patch that allows that; you will need to set
> ac_executable_extensions somewhere (probably config.site).
> 
>   ac_executable_extensions=".exe .com .bat .pl .sh"
> 
> This is what the DJGPP package for 2.50 uses; and once a
> clean, portable way is found to determine the list of executable
> extensions, this should become part of autoconf itself.

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
...
Another possibility would be to introduce a new configure option
--enable-extensions=exe,com,cmd.


> > (autoconf itself does not run with OS/2, but the configure script does)
> Hmm - it probably should...  What particular problems are there?

There seems to be a _lot_ of broken stuff. :-(


[(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"?

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


[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
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)


bye,
Andreas



reply via email to

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