apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: cvs commit: apr STATUS
Date Thu, 23 Aug 2001 15:01:16 GMT
On Wednesday 22 August 2001 21:20, Greg Stein wrote:
> On Thu, Aug 23, 2001 at 04:03:37AM -0000, jerenkrantz@apache.org wrote:
>
> The full text of that item:
>
>     * configure.in does post-processing on the AC_OUTPUT files (for
>       VPATH support). This means that config.status doesn't do the
>       right thing when you re-run it. We ought to revamp the makefiles
>       to do the right AC_SUBST stuff rather than depend upon rewriting.
>
>       Sascha: As the rewriter is a crude hack, I would not worry too
>               much about it.  It is designed to go away once we have
> 	      a proper build system in place.
>
> 	      One of the perceived deficiencies of automake is that it
>               uses AC_SUBST too often, thereby slowing down the task of
> 	      generating Makefiles significantly, because it applies
> 	      dozens of substitutions to each Makefile.  And why?  Make's
>               built-in macro processing is much more powerful, and
> 	      combined with the include facility, generating Makefiles
> 	      becomes simpler and faster.
>
>
> Actually... I believe it is still broken. The Makefile rewriting still
> occurs. Even worse, I just found that Ryan propagated the same thing into
> apr-util.

I didn't have a choice.  The problem is that we wanted to combine the two build
systems, so that APR-util uses APR's build directory.  But, if we substitute the
$(top_builddir) and the INCLUDES variables in the build/rules.mk, then we can't
do this, because APR and APR-util have two different values for those variables.

I looked for another way around, but it looks like the only other solution would be
another file that we include that is project specific.  We can do that, it doesn't bother
me at all, but this just seemed easier to follow.  The speed of a configure doesn't
really bother me all that much.  It is pretty fast as it is now, and most people only
run configure once, but they build it multiple times.  Plus, even if you run configure
multiple times, most of the performance is re-gained for the second run, because
of all of the cached information.

Ryan

> But... none of this rewriting should be required. The rewrite inserts a
> srcdir and VPATH symbol into each makefile. But since we have a #include in
> the Makefile, those two symbols can simply go into rules.mk. Or they can be
> substituted into the Makefiles, along with the @INCLUDE@ substitution.


______________________________________________________________
Ryan Bloom                        	rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Mime
View raw message