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

[William D. Jones]

Hello Dirk,

I’m glad the detail was enough, I thought it might’ve been a bit overkill.

Thank you for taking the time to duplicate my issue, and I apologize for the rather long delay in responding- I’m a grad student first and foremost and I work on this when I can. Your file makes wlink work as intended, and it doesn’t seem like any dependency information is lost by converting the file nodes into strings beforehand (not knowing how SCons works internally, I’m not sure if there is a ‘cascade’ of unintended effects by forcing file nodes to strings).

I’ve seen requests for the OpenWatcom tools on the old mailing, though I’m not sure if the demand is still there (more on that in a bit). Those familiar with Watcom may know that the tools suite comes with a compile and link utility wrapper program which more closely mimics Microsoft or POSIX command line functions, as well as a POSIX-compatible wrapper (currently broken on NT systems). Using those wrappers in SCons are okay for most intents and purposes; normal linker options which are not given alternative switches can also be passed using ‘-<linker directive>’, such as ‘-“output raw”‘ or ‘/”output raw”’ (double quotes typed on command line).

However, there are edge cases where the wrappers will fail- particularly if you need to create a custom system profile (basically, a collection of linker directives to prepend to the linker’s command line internally). The wrappers will read from a list of in it’s system directory and assume a default configuration if no system profile is chosen from a list- this is not the case with wlink. Changing the system profile- short of an ugly ‘hack’ which deletes the current system profile and creates a new one on the same command line- will trigger an error. My project unfortunately is one of those edge cases.


Regarding submitting WATCOM to the wiki- I still have some work to do, but there was a reason I’m hesitant to submit it to the wiki (and asked for advice in incorporating the tools directly into SCons source tree- provided the demand still exists). Disclaimer- my dev environment is anything but ‘normal’ or ‘typical’:

The OpenWatcom tools themselves can replace most Microsoft tools, including clones for the Resource Compiler, CL, and LINK. I one of those unfortunate souls who has Visual Studio Express 2010, for which autodetection is known to fail (http://scons.1086193.n5.nabble.com/Issue-2817-New-scons-does-not-work-with-Visual-Studio-Express-2010-compiler-td7720.html). For a while, I did not think that SCons would correctly autodetect Visual Studio tools and update the path at all. So, for quick projects I just imported my environment, not understanding the process by which SCons does autodetection (it uses the Registry, not just the system path). I use Visual Studio rather sparingly- Watcom (and MinGW) is (are) on my path, and Visual Studio is not. So by importing my external environment, I had SCons thinking it was using Visual Studio tools when it was using the Watcom clones with an incorrectly-updated path because autodetection failed! Wow, SCons not importing the external environment makes a difference after all, huh ?! 

So far, this mixing up has had no ill effects- SCons compiles my own code just fine using the CL/LINK clones while thinking it’s using Visual Studio tools. Although I can’t create a toy example offhand, I can envision there being some scenario where mixing tools (due to subtle incompatibilities) would cause compilation to fail in difficult-to-diagnose ways.  This makes me wonder if it would be reasonable to add logic which distinguishes Watcom’s clones from the tools provided with Visual Studio, and uses the Watcom tools if Visual Studio and MinGW are not present (or if forced using the ‘tools’ option when creating an Environment)?

Thanks again for everyone’s help!

Sincerely,


From: Dirk Bächle 
Sent: Tuesday, August 27, 2013 4:33 PM
To: scons-users at scons.org 
Subject: Re: [Scons-users] Using $SOURCE files with _concat and Command String Parsing

Hi William,

thanks a lot for the detailed description of your current problem. I was able to derive a short SConstruct from it, and could reproduce the failing concatenation on my side.
Searching through the sources, I found an alternative to patching SCons (as suggested by Christopher Murray).
The method "_concat" takes a fifth argument, which is sort of a wrapper that gets applied before it tries to add prefix and suffix to each item of the given list:

  def _concat(prefix, list, suffix, env, f=lambda x: x, target=None, source=None):

By installing your own method "f", you can ensure that the internally created Node instances get converted to simple strings. This prevents the File Nodes from getting skipped in SCons.Defaults, as you stated correctly.

Please find a simple SConstruct attached, which uses the approach above. I hope it works for you, and that we can add a WATCOM Tool to our Wiki index soon. ;)


Best regards,

Dirk

On 25.08.2013 07:08, William D. Jones wrote:

  Hello all,

  [...]
  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

  [...]
    
  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.

  [...]





--------------------------------------------------------------------------------
_______________________________________________
Scons-users mailing list
Scons-users at scons.org
http://four.pairlist.net/mailman/listinfo/scons-users

--
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/20130920/3c339f0a/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1150 bytes
Desc: not available
Url : http://four.pairlist.net/pipermail/scons-users/attachments/20130920/3c339f0a/attachment.png