Mail Archives: djgpp-workers/2001/03/11/07:22:40
> I think config.site should come either with djdev or with Bash. The
> latter is IMHO preferable, since changes in config.site are mostly
> motivated by features supported by the ported Bash.
Either is fine; I still think it's logical that config.site is part
of at least the autoconf source distrib, as its contents are mostly based
on how well autoconf can handle DJGPP, and on how it's implemented (like
for 2.49x, where the use of shell here docs in m4 system() calls requires
setting SHELL/CONFIG_SHELL to a full path). This config.site would then
only include those settings needed for autoconf to work properly on a
djgpp system.
bash and/or djdev (and I'd lean towards djdev) can then include this
config.site, adding those options needed to make configure DTRT on djgpp.
For example the 'base' config.site distributed with autoconf would have
the settings for SHELL/CONFIG_SHELL and TEST_FINDS_EXE (and optionally
PATH),
while the djdev one would add settings such as "ac_cv_func_fork=no".
I already have a paragraph in autoconf's DJGPP readme that explains the
provided config.site should be merged with an existing config.site (if any).
> I think Autoconf is a wrong place to distribute this file, since its most
> important use is to configure and build other packages, and that
> shouldn't require Autoconf to be installed.
True, but different versions of autoconf may require different settings.
A problem may arise if DJGPP packages start using both autoconf 2.13 and
autoconf 2.50 (once that's released); a 2.50-oriented config.site may
break autoconf 2.13 and vice versa. So which version should come with bash?
Maybe each source package should come with its own config.site...
> > PATH="/dev/env/DJDIR/bin;$PATH"
> I think this should first test if %DJDIR%/bin is already in $PATH, and if
> so, remove it. Otherwise, it is unnecessarily bloating PATH, and can
> cause it to overflow, which would make problems if something that uses
> config.site needs to go through COMMAND.COM.
True - didn't think of that. Problem is that detecting $DJDIR/bin may be
non-obvious (might be substed, slashflipped, etc.).
This is mostly intended for maintainers anyway; they'd want config.cache
files to be portable. For regular DJGPP users this is less important, as
their config.cache is only intended for their own system (usually). I'll
comment this out and add a statement to that effect.
- Raw text -