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

[Carl Cerecke]

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