Ben Collins-Sussman <sussman@newton.collab.net> writes:
> > Originally, I thought so too, but now I am of two minds. While it would
> > be nice to just have to put @SVN_TESTS_EDITOR_LIBS@ to get everything
> > you need. Why does this not apply also to say, @SVN_LIBSVN_DELTA@
> > including libexpat, libsvn_subr, etc. If we were to go this way, I say
> > it should then apply to all the @SVN_*@ variables, but if we do this,
> > then people will probably redundantly put things there, not realizing
> > that something else will automiatically grab it.
Redundant link requests should be harmless, like redundant includes.
In an ideal world, if module A depends on module B, bringing in B
should also bring in everything B depends on. A shouldn't need to
know B's requirements -- that's B's job. The whole point of having B
modularized is that A doesn't need to know the details of what goes on
in B, and B's own dependencies are part of those details, I would
think.
The fact that it's difficult to support these clear divisions with our
current technology is not an argument against having them, but it
might be an argument for why we shouldn't spend too much time trying
to achieve perfection.
> Yeah, I agree. Sure, we *could* compress all the build variables down
> to a single variable. But I think that makes things less readable. I
> think it's important to see a real list of dependencies, even if most
> targets have the same list. Our build system is already
> overly-abstracted as it is. =)
No -- we can't compress all the variables down to a single variable,
because a part A depend on two other parts B and C that don't
themselves depend on each other. I think there is an unambiguous
definition of "perfection" here, in which every part automatically
brings in anything it depends on, and doesn't need to be told by its
dependee what those might be.
Whether we can meet that definition, I'm not sure. I certainly don't
think it's worth spending much effort on right now, anyway.
-K
Received on Sat Oct 21 14:36:20 2006