[Top][All Lists]
[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
- autoconf and OS/2, Andreas Büning, 2001/06/15
- Re: autoconf and OS/2, Tim Van Holder, 2001/06/15
- Re: autoconf and OS/2,
Andreas Buening <=
- Re: autoconf and OS/2, Tim Van Holder, 2001/06/15
- Re: autoconf and OS/2, Akim Demaille, 2001/06/18
- Re: autoconf and OS/2, Andreas Buening, 2001/06/18
- Re: autoconf and OS/2, Tim Van Holder, 2001/06/19
- Re: autoconf and OS/2, Andreas Buening, 2001/06/21
- Re: autoconf and OS/2, Tim Van Holder, 2001/06/22
Re: autoconf and OS/2, Akim Demaille, 2001/06/18