[Scons-dev] Accommodating dependency cycles.

[William Blevins]

Team,

Firstly, the dependency cycles users are finding are real, and did not
happen previously. This is because the Command Builder probably didn't have
a source scanner set, the default scanner didn't have keys that mapped to
anything useful, or ...? This means that legitimate cycles that didn't get
discovered by SCons previously are now being discovered with the
appropriate error thrown. For example per
https://pairlist4.pair.net/pipermail/scons-users/2017-March/005742.html

"""

//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

"""

This is analogous to a compiler team fixing validation of syntax that
resulted in code with undefined behavior previously compiling. Anyone who
wrote code that resulted in previously undefined behavior, but just so
happened to work, now has code that doesn't compile.

Since it appears that many users are affected, I looked into trying to
restore the broken behavior specifically for the Command Builder or at
least provide an easy as possible way for the end-user to fix their
situation.

I was hoping the following snippet would restore default behavior,


diff -r 8d7fac5a5e9c src/engine/SCons/Environment.py
--- a/src/engine/SCons/Environment.py    Thu Nov 03 20:09:19 2016 +0000
+++ b/src/engine/SCons/Environment.py    Wed Mar 22 17:22:17 2017 -0400
@@ -1958,9 +1958,12 @@
             'target_factory' : self.fs.Entry,
             'source_factory' : self.fs.Entry,
         }
-        try: bkw['source_scanner'] = kw['source_scanner']
-        except KeyError: pass
-        else: del kw['source_scanner']
+        try:
+            bkw['source_scanner'] = kw['source_scanner']
+        except KeyError:
+            bkw['source_scanner'] = SCons.Scanner.Base( {}, name =
'CommandDefault', recursive = False )
+        else:
+            del kw['source_scanner']
         bld = SCons.Builder.Builder(**bkw)
         return bld(self, target, source, **kw)

but apparently some previous tests expected proper scanning behavior?
    test/Scanner/FindPathDirs.py
    test/Scanner/Scanner.py
    test/Scanner/dictionary.py
    test/Scanner/multi-env.py
    test/Scanner/unicode.py
    test/VariantDir/VariantDir.py
    test/option/debug-stacktrace.py


This implies that for “some reason”, his cpp file was not getting scanned
for implicit dependencies. I don’t know under what conditions this
happened, but I remember the same issue when fixing missing SWIG
dependencies. I needed to set the default scanner set to not empty.

https://bitbucket.org/scons/scons/pull-requests/244/issue-2264-cross-language-scanner-support/diff


SCons.Defaults change snippet follows:

ConstructionEnvironment = {

'BUILDERS' : {},

- 'SCANNERS' : [],

+ 'SCANNERS' : [ SCons.Tool.SourceFileScanner ],

'CONFIGUREDIR' : '#/.sconf_temp',

'CONFIGURELOG' : '#/config.log',

'CPPSUFFIXES' : SCons.Tool.CSuffixes,


If I remove this line, then the following fail:

  test/SWIG/SWIGPATH.py

  test/SWIG/implicit-dependencies.py

  test/SWIG/recursive-includes-cpp.py

  test/VariantDir/VariantDir.py

Long story short, I don’t know a quick and dirty way to “fix” their issue
without giving them a switch which I explained in the dev listing a while
back on how to do. I would need to look up the email chain for that.

Users “could” fix this on their end with a Custom builder or in Command
Builder by setting "source_scanner = SCons.Scanner.Base( {}, name =
'CommandDefault', recursive = False )" or a predefined SCons scanner for
this issue. This will only work on strict use cases though like the example
explicitly given at the beginning of this email. This should disable
scanning for “that” target only unless I misunderstand?

We should probably ask the users directly, but I figured I would get
feedback first. I'm software focused, and not Public Relations focused. If
it were up to me, I would expect the user to not have dependency cycles...

V/R,

William
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20170322/0b91ebbd/attachment-0001.html>