[Scons-dev] Accommodating dependency cycles.

[William Blevins]

Either way before I forget, I want to post a snippet from a side
conversation outside this thread for reference. As described below from
5/2015, use a variable to change node._get_scanner to just be
root_node_scanner to disable.

I haven't checked this against the latest complaints, but I didn't want my
2 year old thoughts to get lost...

----------------------------------------------------

I'm not even sure if we want to make this change, but I did want to have a
plan.

    def get_implicit_deps(self, env, initial_scanner, path_func, kw =
{}):        """Return a list of implicit dependencies for this node.
     This method exists to handle recursive invocation of the scanner
      on the implicit dependencies returned by the scanner, if the
   scanner's recursive flag says that we should.        """
nodes = [self]        seen = {}        seen[self] = 1
dependencies = []        root_node_scanner = self._get_scanner(env,
initial_scanner, None, kw)        while nodes:            node =
nodes.pop(0)
>
> >> simply use root_node_scanner here and do not call _get_scanner again.
This should be easily doable with a variable right?

>             scanner = node._get_scanner(env, initial_scanner, root_node_scanner, kw)            if not scanner:                continue            path = path_func(scanner)            included_deps = [x for x in node.get_found_includes(env, scanner, path) if x not in seen]            if included_deps:                dependencies.extend(included_deps)                for dep in included_deps:                    seen[dep] = 1                nodes.extend(scanner.recurse_nodes(included_deps))        return dependencies
>
>
V/R,
William

On Wed, Mar 22, 2017 at 10:47 PM, William Blevins <wblevins001 at gmail.com>
wrote:

> Here is another one. I assume this round of issues is because they updated
> SCons on the latest Ubuntu. This one actually makes sense. Someone else
> posted this one. "test2.h" explicitly depends on "test.h" via Command
> Builder, and "test.h" implicitly depends on "test2.h" via scanner.
>
> # SConstruct
> Command('test2.h', 'test.h', 'echo "" > test2.h')
> Library('test.c')
>
> // test.c
> #include "test.h"
> #include "test2.h"
>
> // test.h
> #include "test2.h"
>
>
> With 2.3.4, this ran successfully.
>
> With 2.5.0 we have this:
> scons: Reading SConscript files ...
> scons: done reading SConscript files.
> scons: Building targets ...
> scons: done building targets.
>
> scons: *** Found dependency cycle(s):
>   test2.h -> test2.h
>
> On Wed, Mar 22, 2017 at 10:43 PM, William Blevins <wblevins001 at gmail.com>
> wrote:
>
>> Oh, that's true. It depends on itself. It is not a chain per say: A <-->
>> A. Yeah, that is bizarre. I assume he messed up the example, but I copied
>> it verbatim.
>>
>> On Wed, Mar 22, 2017 at 7:39 PM, Gary Oberbrunner <garyo at oberbrunner.com>
>> wrote:
>>
>>>
>>> On Wed, Mar 22, 2017 at 6:15 PM, William Blevins <wblevins001 at gmail.com>
>>> wrote:
>>>
>>>> //source.cpp
>>>> #include "source.gen.h"
>>>> int main() { return 0; }
>>>>
>>>> //SConstruct
>>>> e = Environment()
>>>> e.Command("source.gen.h", "source.cpp", Copy('$TARGET', '$SOURCE')) #
>>>> "generator"
>>>> e.Program("source.cpp")
>>>>
>>>> This code works fine in Scons 2.1, but Scons 2.5.1 produce error:
>>>> scons: *** Found dependency cycle(s):
>>>>   source.gen.h -> source.gen.h
>>>>
>>>> If I'm reading this correctly, I don't see a cycle.
>>> "source" depends on source.cpp and source.gen.h.
>>> source.gen.h depends on source.cpp.
>>> source.cpp is a source, doesn't depend on anything.
>>> Now source.gen.h includes itself, which is weird, but shouldn't all by
>>> itself cause a loop as long as the scanner knows it's already seen that
>>> file.
>>> source.gen.h should definitely not depend on itself.
>>>
>>> (Not saying the current code doesn't detect a cycle, just that in the
>>> abstract there shouldn't actually be one.)
>>>
>>>
>>> --
>>> Gary
>>>
>>> _______________________________________________
>>> Scons-dev mailing list
>>> Scons-dev at scons.org
>>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20170322/4e262ef4/attachment.html>