Re: converting netkit to autoconf?

[Bernd Jendrissek]

On Fri, Sep 13, 2002 at 07:07:33AM -0700, Bruce Korb wrote:
> Akim Demaille wrote:
> > 
> > >>>>> "Paul" == Paul Eggert <address@hidden> writes:
> > 
> > Paul> No, performance is by bigger problem for me, and I think for
> > Paul> most people.  I have lots of disk space, and "configure" scripts
> > Paul> compress well.  But my uniprocessors go only so fast, and
> > Paul> currently "configure" scripts are sequential.  Right now, it
> > Paul> sometimes takes longer to for me to configure a package than to
> > Paul> compile it, and this is ridiculous.
> > 
> > I second this :(  I'm not sure how we can fix this problem though :(
> 
> By separating autoconf into two pieces.  One, a package by itself
> that needs to be installed before an autoconf-ed package gets installed
> and then the new-autoconf package that first checks that its other
> half has already been installed.  The first half does system config
> checks and installs hackaround libraries and other odds and ends,
> the second half uses that information and handles project configuration
> options.  You'd have to bump the major release number.

Do you mean the "second half" stays substantially the same as present
autoconf, while the "first half" would be just a configure.ac with a whole
bunch of AC_FUNC_ALLOCA, AC_FUNC_FORK, AC_TYPE_PID_T and friends?  The
resulting config.h might then be stored into $(localstatedir)/config/ from
where the generated configure of other packages would pick up common tests.

I guess that would mean all the AC_FUNC_*, AC_TYPE_* and maybe the generic
AC_CHECK_FUNC[S] would have to wrap their existing definitions in, say,
AC_CHECK_SHORTCUT(original-macro-name).  AC_CHECK_SHORTCUT would then grep
/var/lib/config/config-shortcuts for original-macro-name and run the "real"
test only if not found.

But what happens when the user configures with CC=uglycc-insane-and-buggy?
Maybe it's a compiler that works just fine, just doesn't support GCC
extensions that may be present when the shortcut tests are compiled.  And
CFLAGS, CPPFLAGS, LIBS, LDFLAGS, etc.?  I strongly suspect that you will
end up just running slow present-day configure just to figure out if you
can use the shortcutted tests.

In fact, wouldn't this pretty much describe the present config cache
mechanism, extended to a system-wide scale?

Maybe the feature test macros just need to test CC, CFLAGS, etc. to see if
they are unchanged from when the shortcuts were generated?  After all, the
feature test macros *know* to which environment variables they are
sensitive.  At least the think they do.  GCC_EXEC_PREFIX anyone?

bernd

-- 
address@hidden is probably better to bookmark than any
employer-specific email address I may have appearing in the headers.
  Vanity page: http://www.tsct.co.za/~berndj/