On Thu, 2002-02-14 at 14:09, John Poltorak wrote: > On Thu, Feb 14, 2002 at 01:31:06PM +0100, Tim Van Holder wrote: > > Yes, I have this line (with -E) in config.site, but config.log shows:- > > > PATH: c:\us in > PATH: c:\emx in > PATH: c:\usr\loca in > PATH: c:\os2 > PATH: .
Probably because this is logged before config.site is run. Again I must point out that the behaviour of ksh's echo could be considered broken; it requires an option to behave 'normally'. This will cause _many_ potential breakages, as people may expect echo NOT to expand anything. I would strongly recommend using sh or bash for running configure scripts. > > > I didn't think autoconf itself used config.site... > > > > I didn't think autoconf itself had a problem; it's a perl script that > > runs m4, so any issues are most likely a bug in the Perl/M4 ports and/or > > the libc used (in the case of system() calls). > > Any special handling would normally only be needed in configure scripts > > produced by autoconf, not in autoconf itself. So config.site is the > > right place to do that. > > What I meant was that I didn't think autoconf derives anything from > config.site... If I put PATH=`echo $PATH...` in config.site, it > won't make any difference to autoconf. It would be preferable if it did > so. Provided you either used '--prefix foo' (where foo is path under which there is a share/config.site file), or set the CONFIG_SITE envvar to point to the site file to use, configure will use it for any package. In fact, my config.site prepends /dev/env/DJDIR/bin to the path, so that DJGPP apps are found in a portable location, and that works fine, including for autoconf.
