Re: autoconf and OS/2

[Andreas Buening]

Tim Van Holder wrote:

[ executable extensions ]


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

This looks more complicated for me. The user is supposed to have a
default
prefix path and a config.site there. If he wants to install the program
somewhere else, he would have to copy config.site. And if his prefix
path is not /usr/local he must pass at least one option to the configure 
script. Additionally he must update config.site to its current system
configuration.

In my opinion a additional configure option would be the best solution
(or a documented environment variable if you like). Why? It doesn't
concern
systems that have no executable extension, but users of all other
systems
have to deal with it in every case. An additional option is easier than
to patch autoconf or the configure script itself.
And last but not least, most times I install a package, I have to use
special options or enviroment variables to get it working. I have no
root permission on our network and to install a large package like lyx
on a non standard Unix like AIX is an adventure.
And using OS/2 is even worse, not even the configure script runs without
modifications, not to mention possible problems with the Makefiles.
*sigh*
I think this is the reason, why most OS/2 ports of GNU packages only
provide a Makefile.os2. :-(
My goal is to have configure scripts running out of the box. :-)


[ config.site ]

> > 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.

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.

Somewhat below is the macro AC_SHELL_PATH_WALK that uses
"IFS=$ac_path_separator"
to split the path into its directories.


[ ln discussion ]

> > 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.

Why should it? If you have a file system that definitly doesn't support
links ln will and must fail in my opinion.


> > 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.

In what way? Do you have an example?

 
> 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.

Agree.


bye,
Andreas