apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@ebuilt.com>
Subject Re: build blues
Date Tue, 13 Feb 2001 21:46:49 GMT
> >    * merged apr-conf.m4 and apr_common.m4 into build/acinclude.m4
> >      and name-protected all of the macro names
> >      -- have not yet name-protected the variables within the macros
> 
> Those two files had two very different uses.  The first is used for APR
> itself, and is a bunch of macros that no application using APR should need
> or even have to think about.  The second is a set of macros that APR
> provides for applications.  I would like to see these kept separate,
> because it makes it much easier for application programmers to locate the
> macros they want to use.

Well, that explains why they were created in the first place (would
have been useful to document that in the files), but that certainly
isn't the case for their contents.  Both had mixed internal and
external macros.  Regardless, the notion that some macros are only
useful for APR and others for its clients just doesn't hold up in
practice -- clients need to know what APR is doing for configure,
which means finding where the macros are defined, which means locating
the macros in one place.  Splitting them up by type of macro would
make sense (like apr_pthreads.m4 and hints.m4).

> >    * removed some unused macros
> 
> such as?

MY_TRY_RUN and another macro which could only be used once as
part of the MM config (and thus was moved inline to configure.in).

> >    * libtoolize --automake --copy --force
> >      [the only way we ever want to call libtoolize]
> 
> why --automake?

It is the option libtoolize is given to tell it to shut up because we
are acting like automake (which we are).  BTW, the --copy means you
can remove the rm and recopy lines from the tarball builder.

> > All of the above is done for apr and it is building fine.  What I still
> > need to do is
> > 
> >    * make each "top-most" buildconf.sh set up the subdirectory configures
> >      directly with autoheader and autoconf, rather than running each of
> >      their buildconf.sh scripts.  This will remove most of the redundant
> >      libtool and configure checks, force the whole tree to be built with a
> >      consistent set of flags, and allow each independent tree's buildconf.sh
> >      to be specialized for standalone builds of that tree.
> 
> Each subdir will still run stand-alone, correct?  There is a part of me
> that dislikes this, because it sounds like it will be possible to
> configure Apache without running APR's buildconf script, which means that
> any bugs in APR's buildconf script are likely to be hidden from a lot of
> the APR developers.

That is a hazard, but buildconf itself should be very small.
I think it is the only way for clients of APR to ensure that their
own builds are consistent (those that don't care can just call
APR's buildconf).  Perhaps more importantly, it makes our
build tree behave more like a traditional autoconf setup, which
should reduce some of the hair-pulling experienced with adjusting
configure for portability.

I wish I could understand why libtool is so archaic.  Why isn't it
just an autoconf macro that sets variables and defines post-process
macros?

....Roy

Mime
View raw message