Mail Archives: djgpp-workers/2001/04/10/12:42:41
> -: Any thoughts on making config.site its own package? It's
> -: contents depend both on Bash and Autoconf so a change in
> either means a
> -: potential update of that file.
>
> Is it realistic for config.site to have [bash] and [autoconf]-specific
> sections, as is done with djgpp.env?
>
I don't see how - it's only used inside configure. It's distributed with
bash because a) configure is a shell script, so you need bash anyway, and
b) because config.site is supposed to smooth over some problems configure
might otherwise have, and since bash also does some of that magic
internally (PATH_SEPARATOR, test -f foo finding foo.exe, etc.), it's
logical for config.site to be geared towards what our bash supports.
As it stands, I'm working to tune autoconf to such a point that many of
the current hacks/workarounds in bash will no longer be necessary for
autoconf. As such, distributing a config.site with autoconf (geared
towards what autoconf needs, rather than towards what bash provides)
is also logical.
The only thing that _would_ be REALLY useful is to have config.site
automagically adjust itself to the version of autoconf that was used to
generate the configure that's being run. autoconf 2.50 requires fewer
and different things than autoconf 2.13, and I don't think a config.site
intended for 2.50 will allow a 2.13 configure to run properly, possibly
require running autoconf to regenerate configure (and because 2.50 is a
major revision, that may require some manual work on configure.in).
- Raw text -