CheckLib fails if PRINT_CMD_LINE_FUNC used

[bdbaddog]

This issue was originally created at: 2010-12-22 05:19:21.
This issue was reported by: reanimator.

reanimator said at 2010-12-22 05:19:21

CheckLib() fails if PRINT_CMD_LINE_FUNC set in environment and .sconsign.dblite removed:

$ rm .sconsign.dblite ; scons -f sconstruct_test
scons: Reading SConscript files ...
Checking for C library magic... no
libmagic.a required for test

The issue may be reproduce with 2.1.0-alpha, 2.0.1, 1.3.1;
Both on cygwin and Linux (sqlite-3.7.2, mysql-python-1.2.3).

The failure root cause is exception in SCons/Job.py:

scons: Configure: Checking for C library magic...
scons: Configure: Caught exception while building ".sconf_temp/conftest_0.c":
 
Traceback (most recent call last):
  File "/usr/lib/scons-1.3.1/SCons/Job.py", line 199, in start
    task.execute()
  File "/usr/lib/scons-1.3.1/SCons/SConf.py", line 358, in execute
    raise e
TypeError: cannot concatenate 'str' and 'list' objects
scons: Configure: no

Here is the simplest sconscript to repoduce the issue:

import sys
import os

def print_cmd_line(s, target, source, env):
    sys.stdout.write(os.linesep + source + os.linesep)
    return
 
# fails if PRINT_CMD_LINE_FUNC given
env = Environment(PRINT_CMD_LINE_FUNC=print_cmd_line)
 
# works if no PRINT_CMD_LINE_FUNC specified
# env = Environment()
 
env['ENV']['PATH'] = os.environ['PATH']
env['LIBPATH'] = ['.']
 
LibraryName         = 'magic'
LibraryFileName     = 'libmagic.a'
ExecName            = 'test'
 
Conf = Configure(env)
 
if not Conf.CheckLib(LibraryName):
    sys.stderr.write(LibraryFileName + ' required for ' + ExecName + os.linesep)
    env.Exit(1)
 
env = Conf.Finish()
 
ExecObj = env.Program(ExecName, ['test.c'], LIBS=[LibraryName], LIBPATH=['.'])

reanimator said at 2010-12-22 05:24:21

Here is the config.log for SCons-2.0.1:

scons: Configure: Caught exception while building ".sconf_temp/conftest_0.c":

Traceback (most recent call last):
 File "/usr/lib/scons-2.0.1/SCons/Job.py", line 201, in start
   task.execute()
 File "/usr/lib/scons-2.0.1/SCons/SConf.py", line 352, in execute
   raise e
TypeError: can't write str to text stream
scons: Configure: no

reanimator said at 2010-12-22 05:25:47

if I change the print_cmd_line
from

sys.stdout.write(os.linesep + source + os.linesep)

to

sys.stdout.write(os.linesep + str(source) + os.linesep)

Then it works scons-1.3.1 on cygwin, but not works with scons-2.0.1 on Linux.

dirkbaechle said at 2010-12-23 07:21:27

Hi Alexander,

I had a first short look at your problem...can you please try

 sys.stdout.write(os.linesep + unicode(source[0]) + os.linesep)

instead of your

 sys.stdout.write(os.linesep + str(source) + os.linesep)

? Please also refer to

https://stackoverflow.com/questions/4512982/python-typeerror-cant-write-str-to-text-stream

and see if this resolves your problem. Please give some feedback about the results, such that we can decide whether to debug the issue further.

Best regards,

Dirk

P.S.: On my machine (Linux, 64bit, SuSE 10.1) I don't get the error, when running the latest SCons version from the trunk. So, it might be worthwhile to give the HEAD revision a spin...

reanimator said at 2010-12-24 01:50:12

unicode(source[0]) works under Linux with scons-2.0.1;

P.S.
I have not tried scons from trunk because of build failure
(error: /usr/lib/python2.6/distutils/command/wininst-6.0.exe: No such file or directory).
Seems to be because of python-2.3 required?!

bdbaddog said at 2010-12-24 09:14:07

re: build issue
python bootstrap.py build/scons-local and then use that.

The package doesn't build on python 2.6 or newer as yet.

[mwichmann]

Is this perhaps an artifact of Python 2's string/unicode disjoint, which got fixed by the restucturing for Python 3 (painful though that was). Proposing we close this as no longer applicable. @bdbaddog

[mwichmann]

Okay, a new look here: when the user-written print_cmd_line is called, source is a list of Value nodes. The function is responsible for dealing with the type of the source and target arguments, so the example here would want to do:

def print_cmd_line(s, target, source, env):
    sys.stdout.write(os.linesep + str(source[0]) + os.linesep)
    return

That seems to work without problem, and is along the lines of what the manpage example does, although that chooses the more advanced form of looping through source (and target), doing str() on each element before printing.

So I'm inclined to say: part user-error, part something that's not a problem any longer.

The PRINT_CMD_LINE_FUNC doc says the callback function thus defined could be called with source and target as node, node list or string - is that true? Then a user-written function would have to be more careful, it would have to account for the single-node or string case also - the example would go awry here as well, not just the exampl in this issue.

So I'd propose close this, and make a small doc fix, either trim the "(file node, list, or string name(s))" in the description to just node-list, or make the example more resilient. Note the default SCons print_cmd_line doesn't run into this because it completely ignores the source and target arguments.

[bdbaddog]

Correct about which arguments it should take, based on looking at Action.py. So go ahead and close.

The example in the manpage will handle all the possibilities except for a string I think, so maybe update that?

[mwichmann]

Correct about which arguments it should take, based on looking at Action.py. So go ahead and close.

The example in the manpage will handle all the possibilities except for a string I think, so maybe update that?

Sorry, which is "correct"? The manpage that lists multiple types? Or my supposition that it's just going to be node-list?

[bdbaddog]

Correct about which arguments it should take, based on looking at Action.py. So go ahead and close.
The example in the manpage will handle all the possibilities except for a string I think, so maybe update that?

Sorry, which is "correct"? The manpage that lists multiple types? Or my supposition that it's just going to be node-list?

Looks like Action.__call__ is only ever called with Node or list of Node objects, which is converted to list in that function before calling the print function.

So you are correct. (though the default ignores target, source, and env)

[mwichmann]

This issue will be closed by merging #4876, which clarifies that the arguments will be lists of nodes, that need to be converted by the callback (as with other functions that deal in source and target arguments). Other parts of this issue are presumably attributable to the Python 2 unicode situation, though since I no longer have such a setup, I can't verify that the problem was reproducible there.