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

[Carl Cerecke]

Actually, the source of the problem isn't in ProtocBuilder, but in
Gch. It has this section of code in the emitter:

    SCons.Defaults.StaticObjectEmitter( target, source, env )
    scanner = SCons.Scanner.C.CScanner()
    path = scanner.path(env)

    deps = scanner(source[0], env, path)    # <-------- This is the problem line

That last line is the one causing error messages like "scons: Cannot
explain why `output/libGch1.o' is being rebuilt: No previous build
information found"

The error message happens even if I'm not using precompiled headers at
all, but just including the builder with env.Tool('gch') in a
SConscript that uses something else that generates .cc files.

I haven't quite figured out how to fix it yet though. I'll keep searching....



On 5 August 2015 at 10:35, 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



-- 
Carl Cerecke
Senior Software Developer

Direct: +64 (9) 929 2572
Skype: carl-compac
Website: www.compacsort.com