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

Tue Jun 4 11:16:33 EDT 2019

Mats and Bill, thank you for help.

I currently solved test problems with Docbook, Clang and Java.

Docbook: 
There is entire "/src" directory previously was removed
from pre-build scons package within build sandbox env.
Now removing of files is more careful. It's spesific for gentoo
as source-based dist and it's build env.

Clang: 
The gentoo installation paths of clang are "   /usr/lib/llvm/*/bin".
So the problem is solved by creation of symlinks for clang and clang++
in /usr/bin or by passing additional paths to SCons env.

Java:
The problem of searching of apropreate include directory
was solved by patching posix.py script to add gentoo
java-jdk installation paths of packages "oracle-jdk-bin",
"openjdk-bin" and "openjdk":

diff -Nur old/scons-3.0.5/src/engine/SCons/Tool/JavaCommon.py new/scons-3.0.5/src/engine/SCons/Tool/JavaCommon.py

--- old/src/engine/SCons/Tool/JavaCommon.py	2019-03-27 02:16:32.000000000 +0300
+++ new/src/engine/SCons/Tool/JavaCommon.py	2019-06-04 10:44:01.000000000 +0300
@@ -403,7 +403,10 @@
 java_macos_version_include_dir = '/System/Library/Frameworks/JavaVM.framework/Versions/%s*/Headers/'
 
 java_linux_include_dirs = ['/usr/lib/jvm/default-java/include',
-                        '/usr/lib/jvm/java-*/include']
+                        '/usr/lib/jvm/java-*/include',
+                        '/opt/oracle-jdk-bin-*/include',
+                        '/opt/openjdk-bin-*/include',
+                        '/usr/lib/openjdk-*/include']
 # Need to match path like below (from Centos 7)
 # /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.191.b12-0.el7_5.x86_64/include/
 java_linux_version_include_dirs = ['/usr/lib/jvm/java-*-sun-%s*/include',

I tested it only for package "oracle-jdk-bin-8.202".
The early failed Java test now is passed.

Суббота, 18 мая 2019, 16:24 +03:00 от Mats Wichmann <mats at wichmann.us>:
>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.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20190604/2fd028bf/attachment.html>
