[Scons-users] Using $SOURCE files with _concat and Command String Parsing

[William D. Jones]

Hello all,

I am working on a moderate-sized project in my spare time and using SCons to manage the build. I am currently running SCons 2.2 and Python 2.7 on Microsoft Windows 7 64-bit Professional.

My project requires use of an x86 assembler, C-compiler which understands Microsoft extensions and a specific linker capable of absolute code-positioning. To that end, I’m using the WATCOM suite of tools to build my source. I am aware that SCons does not have WATCOM support built-in, and so I have built my own rudimentary tools file for the time being. I intend to submit this as a patch in the near-future (but will ask for some guidelines beforehand). Thanks to the built-in environment variables that permit defining prefixes and suffixes for various options, the C compiler and assembler work without major issues. 


Unfortunately, the WATCOM linker, Wlink, has a rather esoteric command line syntax: all linker options must be preceded with a directive. One particular problem with this linker is that every file place on the command line must be preceded with the ‘file’ directive, or alternatively, have a trailing comma after each file.

Assume I have 4 source files, called a.obj, b.obj, c.obj, and d.obj, and want to create a target e.exe. The correct way to link a file such as this is either of the following:

wlink name e.exe option quiet file a.obj file b.obj file c.obj file d.obj
wlink name e.exe option quiet file a.obj, b.obj, c.obj, d.obj

I attempted to make sure SCons adds the file directive prefix by using the built-in _concat function, but concatenation

env['LINK'] = 'wlink'
#env['_LINKSOURCES'] = '${_concat("file ", SOURCES, LINKSUFFIX, __env__)}'
#env['LINKPREFIX'] = 'file '
#env['LINKSUFFIX'] = ''
env['LINKCOM'] = "$LINK name '$TARGET' $LINKFLAGS $_LIBDIRFLAGS $_LIBFLAGS _LINKSOURCES”

According to the SCons source code, SCons.Defaults, line 295 in _concat_ixes(), file nodes (of which $SOURCES is part) are deliberately skipped during _concatenation. I assume there is a logical reason for this, but without this, I cannot seem to create a command line which SCons will accept. That said, is there a means to prefix each source file with the appropriate ‘file ‘ directive without modifying SCons.


Although Wlink doesn’t have a wonderful syntax, it also seems that SCons is modifying the command strings/arguments which are sent to the system, and subsequently incorrectly processed by Wlink. Without quotations around ‘$TARGET’, SCons doesn’t parse the $TARGET variable properly according to wlink, and wlink will complain about a nonexistent directory. Wlink itself ignores the quotes in that context, but SCons passes the quotes to the system. In addition, I have verified that Wlink will accept multiple files without trailing commas or preceding file directive using the following syntax:

env['LINK'] = 'wlink'
...
env['LINKCOM'] = "$LINK name '$TARGET' $LINKFLAGS $_LIBDIRFLAGS $_LIBFLAGS file{$SOURCES}"

Using the example source files above, the new command line becomes:
wlink name ‘e.exe’ option quiet file{a.obj b.obj c.obj d.obj"}

However, for reasons I do not understand, SCons subtly changes the command-line so that trying to link files in this manner causes all but the first and last file (b.obj c.obj) to error out with ‘file not found’. This is consistent with not having quotes around the target with env[‘LINKCOM’]. I believe that SCons is not  setting the command line properly, because setting the ‘LINKCOM’ variable to the final command line directly, without using any other construction variables also results in a successful build (though of course this limits me to one possible executable :P):

env['LINK'] = 'wlink'
...
env['LINKCOM'] = "wlink name ‘e.exe’ option quiet file{a.obj b.obj c.obj d.obj"}

I imagine I can figure out what is wrong by using debug=pdb, but I’m not sure how to set a breakpoint just before a command is executed so that I can see the true command line passed to the system.

Due to the type of object files Wlink outputs, the need for compile for bare-metal hardware, and the absolute code-positing requirements, the linker cannot be replaced easily. But short of editing SCons itself, I do not see a method to get Wlink to behave properly. I am wondering if anyone can suggest a temporary solution that doesn’t require me to edit SCons, or if anyone else has experienced problems with command lines being parsed improperly?

Thank you for your help in advance.

Sincerely,

--
William D. Jones
Rowan University | ECE | 2012
Member IEEE
Member Tau Beta Pi
thor0505 at comcast.net
Message sent using 'Windows Live Mail' client.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://four.pairlist.net/pipermail/scons-users/attachments/20130825/66482456/attachment.htm 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: watcom.py
Url: http://four.pairlist.net/pipermail/scons-users/attachments/20130825/66482456/attachment.ksh