[Scons-users] Honoring the 'SDK shell' settings when using msvc and mssdk tools?

[Andrew C. Morrow]

Hi Dirk -

Thanks for your reply. Comments and follow on questions below.


On Tue, Apr 2, 2013 at 7:37 PM, Dirk Bächle <tshortik at gmx.de> wrote:


> Hi Andrew,

>

>

> On 03.04.2013 00:01, Andrew C. Morrow wrote:

>

>>

>> Sometimes, the msvc and mssdk tools don't do the right thing for various

>> reasons. Sometimes, this is because SCons isn't yet aware of the SDK (SCons

>> 2.3.0 doesn't know about Windows SDK 7.1 or 8, for instance).

>>

>> ...

>>

>> Is there some way to tell the MSCommon tools to skip the whole 'search'

>> aspect and to simply propagate the variables that it would normally set,

>> but with values taken from the invoking shell environment?

>>

>>

> the sdk Tool tries to find the most recent version first, so if it would

> be aware of the v7.1 or v8.0 it would skip the rest.



Apologies if I've misinterpreted your reply, but that answer doesn't seem
to address my question. I actually don't want SCons to do any searching, at
all, since by launching the 'SDK Shell' I've already invoked vcvarsall or
SetEnv.cmd or whatever the Redmond originated horror du jour may be. I
really just want to be able to tell SCons: that work is already done,
please don't do any searching or run any more scripts, just grab the PATH
and whatever else you need for the currently configured version of the SDK
and VC to work and stuff it into the Environment, and set up the COMSTR's
as appropriate to compile and link.

Is there a way to accomplish this?



>

>  Alternatively, is there a way to inject knowledge about new SDKs into the

>> MSCommon framework without requiring the SCons sources to be edited? The

>> lack of support for the Windows 7.1 SDK in SCons 2.3.0 is sort of

>> surprising and frustrating, but if there were a mechanism to inject the

>> required definition then this would go a long way.

>>

>>

> In SCons you can always use the power of Python. So you could try

> something like (untested, and an ugly hack):

>

>   env = Environment(tools=[])

>   import SCons.Tool.MSCommon.sdk as msd

>   # Set new version list

>   msd.SDK71VCSetupScripts =    { 'x86'      : r'bin\vcvars32.bat',

>                            'amd64'    : r'bin\vcvars64.bat',

>                            'x86_amd64': r'bin\vcvarsx86_amd64.bat',

>                            'x86_ia64' : r'bin\vcvarsx86_ia64.bat',

>                            'ia64'     : r'bin\vcvarsia64.bat'}

>   msd.SupportedSDKList = [

>     msd.WindowsSDK('7.1',

>                sanity_check_file=r'bin\**SetEnv.Cmd',

>                include_subdir='include',

>                lib_subdir={

>                    'x86'       : ['lib'],

>                    'x86_64'    : [r'lib\x64'],

>                    'ia64'      : [r'lib\ia64'],

>                },

>                vc_setup_scripts = SDK71VCSetupScripts,

>               )]

>   env.Tool('mssdk')

>

>

Interesting. I hadn't realized that the scoping was so open. This may be
helpful.



>

> , but forking the current source, patching it and creating a pull request

> is the much better approach. ;)

>


Well, that works for fixing master of course. But it doesn't help me if I'm
trying to distribute my project: I can't rely on everyone who grabs my
source using the latest and greatest version of SCons to build. I need to
use whatever they have installed on their system right now, as long as it
meets some reasonable minimum version check.

Thanks,
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://four.pairlist.net/pipermail/scons-users/attachments/20130403/b7bd4369/attachment.html>