[Scons-users] Question about SCons support of python 3.6 and 3.7

[Mats Wichmann]

On 5/18/19 3:54 AM, Sergey Torokhov wrote:
> Mats, great thanks for viewing log files.
> 
> I I re-ran the scons-3.0.5 tests phase with more detailed output (there
> is was "-s") flag in used build script.
> The log only for FAILED tests for python3.6 and 3.7 for scons-3.0.5 : 
> 
> https://cloud.mail.ru/public/4icA/C4kKrmAbd 
> 
> The fails are actually seems distributive specific because package
> manager build and test processes
> are in sandbox environment:
> 
> 1. Some clang tests failed due to "clang" command not found.
> The test that success (e.g. "test/Clang/clang_default_environment.py")
> seems not try run "clang" command. I think it's due to sandbox environment.

A number of test areas follow this model - test what you can without
using the actual external tool (usually using a dummy instead so that
the initialization code "sees" it): make sure the tool initialization is
called, and properly sets up construction variables, etc. which is all
just scons behavior.  Then there are usually some tests that use the
actual tool (this is the case for lex, yacc, m4 and so on, not just clang).

I think you're falling into the hole that the test harness is more
optimistic about searching for tools than scons itself, so yes, this is
problably due to the setup in your sandbox.  Picking just one of the tests:

137/1155 (11.86%) /usr/bin/python3.6 test/Clang/clang_shared_library.py
FAILED test of
/var/tmp/portage/dev-util/scons-3.0.5/work/scons-3.0.5/src/script/scons
        at line 608 of
/var/tmp/portage/dev-util/scons-3.0.5/work/scons-3.0.5/testing/framework/TestCommon.py
(_complete)
        from line 711 of
/var/tmp/portage/dev-util/scons-3.0.5/work/scons-3.0.5/testing/framework/TestCommon.py
(run)
        from line 392 of
/var/tmp/portage/dev-util/scons-3.0.5/work/scons-3.0.5/testing/framework/TestSCons.py
(run)
        from line 51 of test/Clang/clang_default_environment.py
/var/tmp/portage/dev-util/scons-3.0.5/work/scons-3.0.5/src/script/scons
returned 2
STDOUT
=========================================================================
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
clang -o foo.o -c foo.c
scons: building terminated because of errors.

STDERR
=========================================================================
sh: clang: command not found
scons: *** [foo.o] Error 127

But, in the test code:

if not test.where_is('clang'):
    test.skip_test("Could not find 'clang', skipping test.\n")


So the test harness's "where_is" method must have found clang but then
later when the generated SConstruct is run, it isn't in the path used by
scons to find commands.

DefaultEnvironment(tools=[])
env = Environment(tools=['clang', 'link'])
env.SharedLibrary('foo', 'foo.c')



> 2. Docbook tests failed because of failed to load external
> "xmldepend.xsl" for parsing from 
> /var/tmp/portage/dev-util/scons-3.0.5/work/scons-3.0.5/src/engine/SCons/Tool/docbook/utils/
> as this directory with files doesn't exist. For some reasons some files
> was removed from
> build directory now by build script.

Have to wait for Bill (or one of the other old-timers) to comment on
this, but I think if you're running the tests against an _installed_
copy of scons, a number of files from the development tree don't get
installed - the docbook tree is not.  Are you constructing the scons
package, installing in in the sandbox, and testing against that?  It
looks like the docbooks tests might not be entirely applicable in that case.


> 3. Java (I use java-jdk-8-202) test failed because couldn't find "jni.h"
> - I think it just doesn't see appropriate include directory within
> sandbox env too.

> 
> Thank you again for explaining about status of SCons and tips.