[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: hidden dependencies

From: Philip Guenther
Subject: Re: hidden dependencies
Date: Thu, 20 Jan 2011 21:54:13 -0800

On Thu, Jan 20, 2011 at 2:35 AM, Krzysztof Cieniuch
<address@hidden> wrote:
> I think my previous reasoning was incorrect. Order dependencies will work in
> any case
> if some target depends on order dependency that dependency will be rebuild
> first  if outdated it just won't
> trigger rebuild of depending targets. So it is perfect fit for generated
> resources (i.e. everything in project must order depend on generated
> sources)
> with just this side effect that they will be always regenerated, and it is
> "serialization" point in parallel build but that is better then broken
> build.
> So I might to look at this once more. Please correct me if I'm wrong.

Yes, that's how it works in my testing and experience.

> The only maintenance issue is keeping up to date list of modules that
> generate files.

In that previous project, each module generated either a library (with
matching header(s)) or a program.  The Makefile for a library recorded
the include path for accessing the headers it supplied, while the
Makefile for any module that depended on other modules' libraries had
to declare which modules it depended on, so that it could both get
access to the depended upon modules' include files (via their recorded
include paths)...and so that the Makefile system could declare the
order-only dependencies involving all the involved generated header

> My build system includes only necessary makefiles when building project
> module (subdirectory)
> Parsing each time 500 makefiles is not an option since it takes to long (on
> Sun T5440 it takes around 2.5 minute) and if developer is working
> on single module edit/recompile cycle would take to long.

(2.5 min?  Wow, T5440's are even suckier than the hardware that
project had to deal with!)

If each directory declares the directories that it has a dependency
on, then you could restrict your Makefile inclusions to those that are
necessary for the (active) targets.  It does get a bit tricky to get
right, I'll admit.  Once your Makefile setup gets complex enough it
requires testing and debugging like any other program...

(And yes, manually declared module-->module dependencies _are_, in the
end, a manually maintained dependency method that *could* be replaced
with a completely automatic method, but for which the reduction in
per-build computational cost seems to be a reasonable trade-off.
Finding the sweet-spot for doing the automatic<->manual transition is
an aspect of software engineering.

Philip Guenther

reply via email to

[Prev in Thread] Current Thread [Next in Thread]