On Fri, May 25, 2001 at 10:31:56AM -0400, Greg Hudson wrote:
>...
> > On that last bit: GCC's dependencies included every file included,
> > not just the SVN files.
>
> (Your statement is too expansive; the dependencies shouldn't include
> system headers.) How is it supposed to know that the APR files are
> part of a different project?
At the moment, we only include specific headers into dependencies. Namely,
those in the "current directory" and the headers listed in the [includes]
section of build.conf.
> How do you know that a change to apr.h
> doesn't affect the files which include it?
I don't :-) I took the position that we simply assume changes there will
not affect us. Given that APR is supposed to be a library (someday :-), then
it will take pains to avoid binary incompatibility from one version to the
next.
> Why doesn't apr's
> configure script avoid touching apr.h when there is no actual change?
AC_OUTPUT() doesn't do that, AFAIK.
>...
> > shouldn't ever try it. But you can't change that behavior in
> > Automake.
>
> Right with you up until the last line; there's an AM_MAINTAINER_MODE
> option to change that behavior.
Ah. Okee... Thanks.
> > There were some things that we wanted to do which were a giant pain
> > when dealing with those scattered Makefiles. For example: adding the
> > --silent flag to every libtool line.
>
> I'm not sure why Subversion should be different from pretty much all
> other libtool-using programs in regards to the --silent flag, but I'm
> also not sure what the problem is; we seemed to be doing this before
> the build system change via the definition of LIBTOOL.
We had to redefine LIBTOOL in every Makefile.am. I called that "painful" :-)
The --silent flag is handy, preventing a lot of output from spewing during
the build process. And I've never needed the stuff that libtool prints out
(i.e. who cares what it does under the covers; it is just a tool).
> > Or a rule for creating the .la-a files needs when we do a
> > static-link install of mod_dav_svn into an Apache source tree.
>
> This problem is over my head, but I can certainly see how changing the
> object generation rules would be a pain in automake. I'm not actually
> a big fan of automake and don't use it in my own projects, but I do
> use recursive make, and have never seen a compelling reason not to.
Recursive make would be an option, and we could use a system similar to
APR(UTIL) where every Makefile includes a "rules.mk" file. It actually works
reasonably well. But we still have that whole recursion thing going on.
What I find is pretty neat is when you do a "make" now, when everything is
already up-to-date. We get a bazillion lines of output from APR as it
recurses all over the place, telling you "entering directory X" and "leaving
directory X". Then our portion prints nothing. Nice and quiet :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:31 2006