On Thu, Aug 23, 2001 at 04:03:37AM -0000, [EMAIL PROTECTED] wrote:
>...
> @@ -100,6 +104,7 @@
> built-in macro processing is much more powerful, and
> combined with the include facility, generating Makefiles
> becomes simpler and faster.
> + Justin says: "I think this got fixed with Roy's build changes."
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.
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.
In other words, rewriting the Makefiles has never been a good solution.
Sascha even agrees with / points out the "crude hack" part. The right
solution has always been to simply include the right text into the Makefile
to begin with.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
