Mail Archives: djgpp-workers/2001/04/10/14:24:16
> I've noticed that 2.49e has PACKAGE_VERSION containing the version string
> which 2.13 doesn't have. That should be usable in distinguishing the two
> unless PACKAGE_VERSION is tossed in the future. And 2.49e uses
Yes, there's plenty of ways I could depend on autoconf internals to decide
what version it is, but they're internals for a reason. Plus, autoconf
internals tend to change a LOT, so a config.site intended to distinguish
between 2.13 and 2.50 may think 2.51 is 2.13 and break.
> PATH_SEPARATOR, so should the Bash config.site not set
> PATH_SEPARATOR=: as it
> does now?
Ah, good question. The point is that autoconf also AC_SUBSTs PATH_SEPARATOR
to be used in template files (Makefile.in, etc.). There's no guarantee it
will only be used in shell scripts (where bash will make sure it works
properly, as long as it's only used to traverse 'known' PATH-like
variables).
Having PATH_SEPARATOR set to ':' in config.site (or the environment, for
that matter), would "break" autoconf's pathsep check and cause it to use
':' everywhere; this is not a problem as long as it is only used in
configure and sh-based Makefiles, but may break some other packages.
Using ';' on DOS is more natural anyway, and autoconf can be used to
propagate the correct pathsep to the necessary files (for example, my
local ld tree has a genscripts.in file that autoconf transforms to
genscripts.sh, so it uses ';' instead of ':' where appropriate).
- Raw text -