[Scons-users] Not clobbering autodetected HOST_ARCH when configured via Options

Wed Jul 9 14:35:52 EDT 2014

Well the logic should be:

HOST = x86, TARGET = X86  -> VC/bin
HOST = x86_64, TARGET = X86  -> VC/bin
HOST= x86, TARGET =x86_64 -> vc/bin/x86_AMD64
HOST= x86_64, TARGET =x86_64 -> vc/bin/AMD64

If this is not happening I would say this is bug in the SCons version of msvc. I would be surprised as I know this was working before, however maybe it broke with new version of the compilers.

I only helped out with the rewrite of this years ago ( pushed to get the HOST and TARGET stuff in ) it clearly has changed a bit since I last used it. For me I have a add on called Parts with has improved logic, so I have all this for intelc, gcc, g++ and msvc for x86, x86_64, arm. You can use it with raw SCons file ( vs breaking up stuff in to Parts file under the sconstruct). Just down load it from part.tigris.org ( under the download tab) and install it.

A simple example would be:

# Sconstruct
from parts import *
Default(Program('a2','a.c'))

You should be able to say then.

Scons --target=x86 

And on window Scons will default to the latest version of cl ( given intelc is not installed) and build a 32 bit for you... ie you should see this:

scons: done reading SConscript files.
Parts: Updating disk
Parts: Updating disk - Done
Parts: Loaded 0 Parts
scons: Building targets ...
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\cl.EXE" /Foa.obj /c a.c /DMSVC_VERSION=12.0 /nologo /Od /MDd /W3 /RTC1 /DWIN32 /D_WINDOWS /DPAT_DEBUG /D_WIN32_WINNT=0x601
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\link.EXE" /incremental:no /OUT:a2.exe a.obj
scons: done building targets.
Parts: Storing Data Cache
Parts: Done -- Storing Data Cache

Hopefully this will help you use SCons as it is really a great build tool ( ie I think a bit better with Parts, but I am bias :-) )

Jason

-----Original Message-----
From: Scons-users [mailto:scons-users-bounces at scons.org] On Behalf Of Andrew C. Morrow
Sent: Wednesday, July 9, 2014 12:39 PM
To: SCons users mailing list
Subject: Re: [Scons-users] Not clobbering autodetected HOST_ARCH when configured via Options

How does one select the 32-to-64 cross compiler when running on a 64-bit host without setting HOST_ARCH?

On such a system:

TARGET_ARCH=x86_64 will use the VC/bin/amd64 compiler (64 to 64)
TARGET_ARCH=x86 will use the VC/bin compiler (32 to 32)

If someone working on a 32-bit machine reports a build problem when cross compiling to 64-bits, and I'm working on a 64-bit machine, I'd like to be able to repro their build, including the compiler. Setting HOST_ARCH to x86 seems to accomplish that.

I'm certainly open to other mechanisms if HOST_ARCH is really not to be set.

On Wed, Jul 9, 2014 at 1:14 PM, Kenny, Jason L <jason.l.kenny at intel.com> wrote:
> The goal is that you set the TARGET_ARCH value in SCons to set the cross compiler logic in the MSVC tool.
>
> The logic assumes that we want to target the same system as the host. If you are doing something different, such as doing a 32-bit build on a 64-bit system, you will want to set the TARGET_ARCH to x86. The Host tell the tool how to find the tool on the given system based on the requested target.
>
> I hope that helps.
> Jason
>
> -----Original Message-----
> From: Scons-users [mailto:scons-users-bounces at scons.org] On Behalf Of 
> Andrew C. Morrow
> Sent: Wednesday, July 9, 2014 12:04 PM
> To: SCons users mailing list
> Subject: Re: [Scons-users] Not clobbering autodetected HOST_ARCH when 
> configured via Options
>
> On Wed, Jul 9, 2014 at 12:46 PM, Kenny, Jason L <jason.l.kenny at intel.com> wrote:
>> HOST_ARCH should not be set by the user. HOST here is the system you are building on. TARGET is what you are building for.
>
> At least some Express versions of VS don't ship the 64-bit compiler.
> They only ship the 32 bit compiler, and the 32-to-64 cross compiler.
> If you are building on a 64 bit machine where HOST_ARCH autodetects to
> x86_64 and try to do a TARGET_ARCH=x86_64 build, it fails because it can't invoke the 64-bit compiler, since it isn't present.
>
> You can cheat by setting PROCESSOR_ARCHITECTURE=x86 in the cmd.exe environment before invoking SCons, which fakes out the HOST_ARCH autodetection, but I'd prefer to allow users who are facing this difficulty the option of explicitly setting HOST_ARCH=x86 to select the cross compiler.
>
> But HOST_ARCH is just an example here. The question is really about how to deal with passing possibly empty option values to the Environment constructor without disturbing defaults.
>
>
>>
>> Jason
>>
>> -----Original Message-----
>> From: Scons-users [mailto:scons-users-bounces at scons.org] On Behalf Of 
>> Andrew C. Morrow
>> Sent: Wednesday, July 9, 2014 11:44 AM
>> To: SCons users mailing list
>> Subject: [Scons-users] Not clobbering autodetected HOST_ARCH when 
>> configured via Options
>>
>> The following question uses HOST_ARCH because it is the construction variable that was giving me trouble, but I think the question applies to any construction variable that, if it is to be customized, must be set at Environment construction time.
>>
>> I can set up HOST_ARCH reasonably using Variables:
>>
>> variables = AddVariables(
>>     (HOST_ARCH, "The host architecture for Windows builds"),
>> )
>>
>> env = Environment(variables=variables).
>>
>> The above does the right thing whether or not HOST_ARCH is passed to scons:
>>
>> # OK, HOST_ARCH will be autoselected by SCons internals
>>> scons
>>
>> # OK, HOST_ARCH will be set to x86
>>> scons HOST_ARCH=x86
>>
>>
>> If, instead, I want to manage HOST_ARCH via Options for consistency with a project that currently uses Options for everything:
>>
>> AddOption('--host-arch', ...)
>>
>> env = Environment(
>>     HOST_ARCH=GetOption('host-arch'))
>> )
>>
>> Then all is well if I pass --host-arch:
>>
>> # OK, HOST_ARCH gets the value of --host-arch
>>> scons --host-arch=x86
>>
>> But if I don't set the option, things are not OK:
>>
>> # NOT OK, HOST_ARCH becomes 'None' in Environment, instead of taking autoselected value:
>>> scons
>>
>> The documentation states that HOST_ARCH must be set at construction time, so I can't optionally do it later. One thought was to build the argument dictionary to the Environment constructor incrementally, and then pass it as the kwargs:
>>
>> envdict = dict()
>>
>> if GetOption('host-arch'):
>>     envdict['HOST_ARCH'] = GetOption('host-arch')
>>
>> env = Environment(**envdict);
>>
>> What is the preferred mechanism for optionally setting Environment variables without disturbing defaults?
>>
>> Thanks,
>> Andrew
>> _______________________________________________
>> Scons-users mailing list
>> Scons-users at scons.org
>> http://four.pairlist.net/mailman/listinfo/scons-users
>> _______________________________________________
>> Scons-users mailing list
>> Scons-users at scons.org
>> http://four.pairlist.net/mailman/listinfo/scons-users
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> http://four.pairlist.net/mailman/listinfo/scons-users
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> http://four.pairlist.net/mailman/listinfo/scons-users
_______________________________________________
Scons-users mailing list
Scons-users at scons.org
http://four.pairlist.net/mailman/listinfo/scons-users