cvs commit: hugs98/src config.h.in hugs98/src/unix acconfig.h aclocal.m4 configure configure.in
ross 2003/08/23 03:34:44 PDT Modified files: src config.h.in src/unix acconfig.h aclocal.m4 configure configure.in Log: minimal tracking of recent changes in fptools/configure -- in time, we may need to bite the bullet and commit to recent versions of autoconf/autoheader and reuse the fptools stuff. Revision Changes Path 1.30 +101 -98 hugs98/src/config.h.in 1.15 +101 -98 hugs98/src/unix/acconfig.h 1.19 +1 -1 hugs98/src/unix/aclocal.m4 1.71 +64 -3 hugs98/src/unix/configure 1.76 +2 -0 hugs98/src/unix/configure.in
On Saturday 23 August 2003 11:34 am, ross@glass.cse.ogi.edu wrote:
minimal tracking of recent changes in fptools/configure -- in time, we may need to bite the bullet and commit to recent versions of autoconf/autoheader and reuse the fptools stuff.
I haven't been following this all that closely so this may be a silly question: Is there any reason _not_ to use a recent version? It seems like there's no penalty if the autoconf file exists (e.g., in source distros where we've run autoconf) and those using cvs are probably capable of installing a recent enough autoconf version? It's cool to leave it with the old version but I'm just wondering why you're hesitant to do so. -- Alastair
On Sat, Aug 23, 2003 at 09:39:54PM +0100, Alastair Reid wrote:
On Saturday 23 August 2003 11:34 am, ross@glass.cse.ogi.edu wrote:
minimal tracking of recent changes in fptools/configure -- in time, we may need to bite the bullet and commit to recent versions of autoconf/autoheader and reuse the fptools stuff.
I haven't been following this all that closely so this may be a silly question:
Is there any reason _not_ to use a recent version? It seems like there's no penalty if the autoconf file exists (e.g., in source distros where we've run autoconf) and those using cvs are probably capable of installing a recent enough autoconf version?
It's cool to leave it with the old version but I'm just wondering why you're hesitant to do so.
You're probably right. It will take a bit of reorganization, though. Moving to autoheader2.50 will mean merging options.h and config.h, and getting rid of acconfig.h. We could distinguish the user-tweakable defines by renaming them ADD_FOO, I suppose. I'm not sure if that would be OK for non-Unix builds. Fixing on a recent autoconf would be easier.
participants (3)
-
Alastair Reid -
Ross Paterson -
ross＠glass.cse.ogi.edu