Re: [boost] Boost Modularization: did we get it right?

Subject: Re: [boost] Boost Modularization: did we get it right?
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2012-05-11 00:48:56

AMDG

On 05/10/2012 08:48 PM, Bjørn Roald wrote:
> 
> Algorithm looks good to me as far as what to create when a missing link
> is detected.
> 
> Whether you have captured the rest of what should be there it is not
> clear to me. My ignorance of the details of bjam and Boost.Build, and
> thus my understanding of the effect of your patches does not allow me to
> understand in a glance.  So I ask instead.
> 
> Does your solution provide proper functioning build graph including the
> derived forward header links or files?
> 

I haven't tested it, so it probably doesn't.
It should just be a matter of adding any
dependencies that I've forgotten.  It looks
like I need to add dependencies for hardlinks
and copies.  sym-links don't need the dependency,
since they're guaranteed to be correct as
long as they exist.  The include scanner
does work correctly with generated headers,
so no source should be built before the
headers that it depends on.

> Symbolic and hard links are services of the file system and when set up
> correctly, they should work transparently to the build system as though
> it looks at the source files.
> 
> bjorn_at_frodo2:/tmp/linkjunk$ touch a
> <snip>
> 
> note the time of a_symb is older than the file a after last touch of a. 
> Horror.  Does the build graph analysis handle this correctly.  Note also
> that hard links are OK.
> 

stat returns information on the target
of the link, so it should be okay.  I
haven't checked what happens on Windows,
yet.

> Cleanup of derived forwarding headers and links when source are moved or
> deleted is a bit more tricky than support to create them.  Any hope of
> support for this?
> 

Given that multiple directories are being
merged, we have no way of knowing that
any extra files aren't from a source that
exists but didn't happen to be mentioned
in the current build.  With directory
sym-links, this shouldn't be much of a
problem, though.  Anyway, the extra
links should be harmless and it's easy
enough to delete and regenerate the entire
directory once in a while.

> A side note: A really smart build system should detect changes in
> content of the source files, not just a forward motion of file time. 
> But this is probably both costly and a very fundamental change.  I think
> lack of such a feature may bite us more with modularized boost as it is
> simpler to change a parts in your build graph to an earlier versions
> without realizing the need for clean builds.
> 

It's not as costly as you might think, since
the include scanner already reads in most
of the source files, so the IO cost is already
incurred.  I'll consider this after I get
around to updating HCACHE to work better
with Boost.Build.

In Christ,
Steven Watanabe