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 <[email protected]>
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 <[email protected]>
> 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 <[email protected]>
>> wrote:
>>
>>>
>>> On Wed, Mar 22, 2017 at 6:15 PM, William Blevins <[email protected]>
>>> 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
>>> [email protected]
>>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>>
>>>
>>
>
_______________________________________________
Scons-dev mailing list
[email protected]
https://pairlist2.pair.net/mailman/listinfo/scons-dev
