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

[William Blevins]

Addendum,

I was using it for Java though which isn't explicitly supported, so that
experience may not be relevant.

V/R,
William

On Tue, Aug 4, 2015 at 7:25 PM, William Blevins <wblevins001 at gmail.com>
wrote:

> 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/7f222f9a/attachment.html>