[Scons-users] Previous build information lost with ProtoBuilder/Gch interaction

[William Blevins]

I've used the protoc builder before.  The emitter doesn't always behave
correctly, so I end up with dependency graphs changing between runs.

My solution was to generate code from the proto files separately and commit
them.  In general, I always like to track generated code deltas anyway.

V/R,
William

On Tue, Aug 4, 2015 at 6:35 PM, Carl Cerecke <carl.cerecke at compacsort.com>
wrote:

> Thanks Dirk and William,
>
> I think I've tracked the problem down to something in ProtocBuilder
> (https://bitbucket.org/scons/scons/wiki/ProtocBuilder). I've filed a
> bug report:
> https://bitbucket.org/russel/scons_protobuf/issues/3/wrong-dependency-tree-when-using-variant
>
> I've still no idea how to fix it though; it's seems like really weird
> behaviour. So no patch at the moment, sorry.
>
> Cheers,
> Carl.
>
> On 4 August 2015 at 19:12, Dirk Bächle <tshortik at gmx.de> wrote:
> > Hi Carl,
> >
> > On 04.08.2015 04:36, Carl Cerecke wrote:
> >>
> >> I have two Sconscript files, both building a single static library,
> >> and both called from the same SConstruct (they are the only two
> >> Sconscript files called).
> >>
> >> [...]
> >>
> >> Building from scratch works fine.
> >>
> >> Problem: Rebuilding (after no changes) builds everything again and
> >> [...]
> >>
> >> What is utterly confusing is that, whether or not libGch finds
> >> previous build information or not, depends on whether an unrelated
> >> dependency exists in a *separate* Sconscript file that should be
> >> completely independent!
> >>
> >> Both Sconscript files use a clone of the environment they imported
> >> from the parent SConstruct, so they should be independent.
> >>
> > just to make a few things clear. The Nodes of the different environments
> are
> > treated separately, regarding how they are created...meaning: the single
> > Actions of the Builder are executed in the Environments as you've
> specified
> > them.
> > However, the dependency tracking between the single targets (like
> Programs,
> > Libraries,...) and back to their sources, always operates on the full VFS
> > (virtual filesystem). With VFS I don't mean the dependency tree (DAG)
> that
> > SCons implicitly creates during the build phase. It's a tree structure
> where
> > SCons keeps track of which Nodes (Targets/Sources/Generated headers/...)
> > exist, or should come into existence later during the actual build. This
> > "file tree" is fed from the info (basically stemming from the Emitters of
> > the single Builders, "what goes in, and what goes out?") in *all* your
> > SConstructs/SConscripts that are read in.
> >
> > And this is done so by design. Because we *want* to automatically detect
> a
> > dependency between a library "libfoo" and a main program "bar", even if
> both
> > are created in different Environments. So, the behaviour that you see is,
> > more or less, expected...
> >
> > In addition to what William said, I'd also like to have a closer look at
> > some of your example code before making any further claims and statements
> > about what could possibly go wrong.
> >
> > Best regards,
> >
> > Dirk
> >
> >
> > _______________________________________________
> > Scons-users mailing list
> > Scons-users at scons.org
> > https://pairlist4.pair.net/mailman/listinfo/scons-users
>
>
>
> --
> Carl Cerecke
> Senior Software Developer
>
> Direct: +64 (9) 929 2572
> Skype: carl-compac
> Website: www.compacsort.com
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20150804/ed6367a9/attachment-0001.html>