[Scons-users] Catching 'None' dependencies

[H. S. Teoh]

On Mon, Apr 28, 2014 at 07:33:03PM +0200, Dirk Bächle wrote:

> On 28.04.2014 19:07, H. S. Teoh wrote:

> >[...]

> >Unfortunately this didn't help. All it does is to indicate which

> >sequence of nodes lead to the node that depends on 'None', but by

> >this point the dependency graph has already been constructed. What I

> >need to know is which part of the SConscript / SConstruct is

> >responsible for adding this wrong dependency into the graph in the

> >first place.

> >

> >Is there a way, inside an SConscript, to extract the current list of

> >dependencies for a particular node?

> 

> The list of implicit dependencies for each Node is built during the

> "build phase", by scanning files as soon as they exist. So, checking

> them in the "read phase" while parsing SConstructs/SConscripts won't

> help.  Do you have custom scanners/builders in your setup? Maybe you

> can track this further down by specifying targets explicitly, like

> "scons mylib". Are there subtrees of your dependency graph, that don't

> create the "None" node? This might give you a further clue about where

> the error comes from...

[...]

Aha, that's it. I found the problem in one of my custom scanners.

The problem is caused by the scanner expanding a list of #include's
using SCons' FindFile method, which has the quirky behaviour where if
the file being searched for isn't found in any of the search
directories, it will return '/path/to/None' where '/path/to/' appears to
be the path of the source file being scanned.

The root cause of the problem was that I upgraded one of the build
programs, which changed the location of its system #include files, but I
failed to update the SConstruct to reflect this new location. This in
turn triggered the quirk in FindFile that returns '/path/to/None'.

Maybe FindFile should be updated to raise an error if the file can't be
found? Now that I traced the problem to this, I recall that this same
quirk has caused me similar problems in the past. Returning
'/path/to/None' is a very counterintuitive way of indicating that the
file couldn't be found, IMO!

Or is the use of FindFile in a scanner a bad idea? If so, what's the
correct alternative?


--T