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

[Carl Cerecke]

I've solved the problem by changing
https://bitbucket.org/scons/scons/wiki/GchBuilder to use a
hacked-together scanner for includes rather than
SCons.Scanner.C.CScanner(). Seems to work OK for me, anyway.

Code is at https://gist.github.com/cdjc/e75f7925c12adfd3b8ea if
anyone's interested.

Cheers,
Carl.

On 7 August 2015 at 11:07, Carl Cerecke <carl.cerecke at compacsort.com> wrote:
> 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



-- 
Carl Cerecke
Senior Software Developer

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