Support LINKFLAGS #25
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bdbaddog
changed the title
mwichmann
added a commit
to mwichmann/scons
that referenced
this pull request
Aug 3, 2019
Minor changes for compatibility.
Cannot currently run these tests effectively:
1. One of the bench runs doesn't work on Py3 yet. is_types.py fails
with:
```
Traceback (most recent call last):
File "bench.py", line 91, in <module>
exec(open(args[0], 'r').read())
File "<string>", line 16, in <module>
AttributeError: module 'types' has no attribute 'InstanceType'
```
The test fundamentally depends on checking if a type is an instance
as part of what's being timed; the problem is types.InstanceType
was only meaningful for old-style classes where all instances have
the same type. Since that can't happen in Python 3 with new-style
classes only, types.InstanceType has been removed entirely. Is
it worth trying to figure out how to rejigger the test?
2. The calibrarions on the timings configs are horribly wrong for the
local machine (10x too small), but not sure what to calibrate them for.
3. The calibration algorithm sometimes goes off base. The objective
is to converge on something just under 10 seconds, and hit it three
times in a row. In this snippet SCons#25 got close, then we keep iterating
and get further away in SCons#27, SCons#29, SCons#31, SCons#33 (this particular calibration
eventually hit it's three with runs SCons#55-57.
```
run 25: 9.207: TARGET_COUNT=1019
run 26: 11.026: TARGET_COUNT=1106
run 27: 8.630: TARGET_COUNT=1003
run 28: 12.046: TARGET_COUNT=1162
run 29: 8.240: TARGET_COUNT=964
run 30: 12.062: TARGET_COUNT=1169
run 31: 8.232: TARGET_COUNT=969
run 32: 12.470: TARGET_COUNT=1177
run 33: 8.185: TARGET_COUNT=943
```
4. Running any of the timings fails with stdout mismatch, as there is
(unexpected?) timing output. Example CPPPATH - see the second line
of the captured output for the extra data. Is this new data emitted
by debug=time that the timings code is not expecting?
```
/home/mats/.pyenv/versions/python-3.7.3/bin/python /home/mats/github/scons/src/script/scons.py DIR_COUNT=813 --debug=memory,time .
STDOUT =========================================================================
1,6c1,14
< scons:\ Reading\ SConscript\ files\ \.\.\.\
< scons:\ done\ reading\ SConscript\ files\.\
< scons:\ Building\ targets\ \.\.\.\
< scons:\ `\.'\ is\ up\ to\ date\.\
< scons:\ done\ building\ targets\.\
< .*
---
> scons: Reading SConscript files ...
> SConscript:/tmp/testcmd.256448.xbxk_gj1/SConstruct took 107.051 ms
> scons: done reading SConscript files.
> scons: Building targets ...
> scons: `.' is up to date.
> scons: done building targets.
> Memory before reading SConscript files: 139239424
> Memory after reading SConscript files: 145399808
> Memory before building targets: 145399808
> Memory after building targets: 148684800
> Total build time: 0.311640 seconds
> Total SConscript file execution time: 0.107460 seconds
> Total SCons execution time: 0.204180 seconds
> Total command execution time: 0.000000 seconds
FAILED test of /home/mats/github/scons/src/script/scons.py
...
from line 53 of timings/CPPPATH/TimeSCons-run.py
```
5. CPPPATH timing config runs into a command-line length problem if
calibrating. Might be a testcase for using a file for long command
lines even in the gcc case?
```
run 1: 0.490: DIR_COUNT=813
1/1 (100.00%) /home/mats/.pyenv/versions/python-3.7.3/bin/python timings/CPPPATH/TimeSCons-run.py
/home/mats/github/scons/src/script/scons.py returned 2
STDOUT =========================================================================
scons: Reading SConscript files ...
SConscript:/tmp/testcmd.253125.kkqcvz12/SConstruct took 1186.979 ms
scons: done reading SConscript files.
scons: Building targets ...
gcc -o foo.o -c -Iinc_0000 -Iinc_0001 -Iinc_0002
... incredibly long line chopped ...
Iinc_16574 -Iinc_16575 -Iinc_16576 -Iinc_16577 -Iinc_16578 -Iinclude foo.c
scons: building terminated because of errors.
Memory before reading SConscript files: 139243520
Memory after reading SConscript files: 233705472
Memory before building targets: 233705472
Memory after building targets: 255672320
Total build time: 5.079720 seconds
Total SConscript file execution time: 1.189501 seconds
Total SCons execution time: 3.890219 seconds
Total command execution time: 0.000000 seconds
FAILED test of /home/mats/github/scons/src/script/scons.py
...
from line 53 of timings/CPPPATH/TimeSCons-run.py
STDERR =========================================================================
scons: *** [foo.o] sh: Argument list too long
Traceback (most recent call last):
File "bin/calibrate.py", line 88, in <module>
sys.exit(main())
File "bin/calibrate.py", line 69, in main
elapsed = float(em.group(1))
AttributeError: 'NoneType' object has no attribute 'group'
```
Signed-off-by: Mats Wichmann <mats@linux.com>
3 tasks
mwichmann
added a commit
to mwichmann/scons
that referenced
this pull request
Aug 31, 2019
Minor changes for compatibility.
Cannot currently run these tests effectively:
1. One of the bench runs doesn't work on Py3 yet. is_types.py fails
with:
```
Traceback (most recent call last):
File "bench.py", line 91, in <module>
exec(open(args[0], 'r').read())
File "<string>", line 16, in <module>
AttributeError: module 'types' has no attribute 'InstanceType'
```
The test fundamentally depends on checking if a type is an instance
as part of what's being timed; the problem is types.InstanceType
was only meaningful for old-style classes where all instances have
the same type. Since that can't happen in Python 3 with new-style
classes only, types.InstanceType has been removed entirely. Is
it worth trying to figure out how to rejigger the test?
2. The calibrarions on the timings configs are horribly wrong for the
local machine (10x too small), but not sure what to calibrate them for.
3. The calibration algorithm sometimes goes off base. The objective
is to converge on something just under 10 seconds, and hit it three
times in a row. In this snippet SCons#25 got close, then we keep iterating
and get further away in SCons#27, SCons#29, SCons#31, SCons#33 (this particular calibration
eventually hit it's three with runs SCons#55-57.
```
run 25: 9.207: TARGET_COUNT=1019
run 26: 11.026: TARGET_COUNT=1106
run 27: 8.630: TARGET_COUNT=1003
run 28: 12.046: TARGET_COUNT=1162
run 29: 8.240: TARGET_COUNT=964
run 30: 12.062: TARGET_COUNT=1169
run 31: 8.232: TARGET_COUNT=969
run 32: 12.470: TARGET_COUNT=1177
run 33: 8.185: TARGET_COUNT=943
```
4. Running any of the timings fails with stdout mismatch, as there is
(unexpected?) timing output. Example CPPPATH - see the second line
of the captured output for the extra data. Is this new data emitted
by debug=time that the timings code is not expecting?
```
/home/mats/.pyenv/versions/python-3.7.3/bin/python /home/mats/github/scons/src/script/scons.py DIR_COUNT=813 --debug=memory,time .
STDOUT =========================================================================
1,6c1,14
< scons:\ Reading\ SConscript\ files\ \.\.\.\
< scons:\ done\ reading\ SConscript\ files\.\
< scons:\ Building\ targets\ \.\.\.\
< scons:\ `\.'\ is\ up\ to\ date\.\
< scons:\ done\ building\ targets\.\
< .*
---
> scons: Reading SConscript files ...
> SConscript:/tmp/testcmd.256448.xbxk_gj1/SConstruct took 107.051 ms
> scons: done reading SConscript files.
> scons: Building targets ...
> scons: `.' is up to date.
> scons: done building targets.
> Memory before reading SConscript files: 139239424
> Memory after reading SConscript files: 145399808
> Memory before building targets: 145399808
> Memory after building targets: 148684800
> Total build time: 0.311640 seconds
> Total SConscript file execution time: 0.107460 seconds
> Total SCons execution time: 0.204180 seconds
> Total command execution time: 0.000000 seconds
FAILED test of /home/mats/github/scons/src/script/scons.py
...
from line 53 of timings/CPPPATH/TimeSCons-run.py
```
5. CPPPATH timing config runs into a command-line length problem if
calibrating. Might be a testcase for using a file for long command
lines even in the gcc case?
```
run 1: 0.490: DIR_COUNT=813
1/1 (100.00%) /home/mats/.pyenv/versions/python-3.7.3/bin/python timings/CPPPATH/TimeSCons-run.py
/home/mats/github/scons/src/script/scons.py returned 2
STDOUT =========================================================================
scons: Reading SConscript files ...
SConscript:/tmp/testcmd.253125.kkqcvz12/SConstruct took 1186.979 ms
scons: done reading SConscript files.
scons: Building targets ...
gcc -o foo.o -c -Iinc_0000 -Iinc_0001 -Iinc_0002
... incredibly long line chopped ...
Iinc_16574 -Iinc_16575 -Iinc_16576 -Iinc_16577 -Iinc_16578 -Iinclude foo.c
scons: building terminated because of errors.
Memory before reading SConscript files: 139243520
Memory after reading SConscript files: 233705472
Memory before building targets: 233705472
Memory after building targets: 255672320
Total build time: 5.079720 seconds
Total SConscript file execution time: 1.189501 seconds
Total SCons execution time: 3.890219 seconds
Total command execution time: 0.000000 seconds
FAILED test of /home/mats/github/scons/src/script/scons.py
...
from line 53 of timings/CPPPATH/TimeSCons-run.py
STDERR =========================================================================
scons: *** [foo.o] sh: Argument list too long
Traceback (most recent call last):
File "bin/calibrate.py", line 88, in <module>
sys.exit(main())
File "bin/calibrate.py", line 69, in main
elapsed = float(em.group(1))
AttributeError: 'NoneType' object has no attribute 'group'
```
Signed-off-by: Mats Wichmann <mats@linux.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This issue was originally created at: 2001-07-30 22:00:00.
This issue was reported by:
stevenknight.stevenknight said at 2001-07-30 22:00:00
issues@scons said at 2001-07-30 22:00:00
stevenknight said at 2006-05-20 20:50:37