[Scons-users] compiler detection

[Kraus Philipp]

Am 03.11.2012 um 21:01 schrieb William Deegan:


> Phil,

> On Oct 30, 2012, at 3:36 AM, Kraus Philipp <philipp.kraus at flashpixx.de> wrote:

> 

>> 

>> Am 30.10.2012 um 06:08 schrieb Evan Driscoll:

>> 

>>> On 10/29/2012 9:16 PM, Evan Driscoll wrote:

>>>> SCons will always behave the same regardless of how you start it. If

>>>> 'scons' runs the native SCons, it will always use cmd.exe by default

>>>> regardless of whether it is being started under Cygwin or cmd. If

>>>> 'scons' runs Cygwin SCons, then it will always use Cygwin's sh.exe by

>>>> default regardless of whether it is being started under Cygwin or cmd.

>>>> (But see below.)

>>> 

>>> Actually my rant there, while *mostly* right, has some inaccuracies.

>>> What matters is not where SCons per se came from but rather what Python

>>> is used to run it. So if you install SCons for native Python but then

>>> run it with Cygwin Python, you'll get Cygwin behavior (SHELL is sh and

>>> CC is gcc); if you install SCons for Cygwin Python but then run it with

>>> native Python, you'll get native behavior (SHELL is cmd.exe and CC is

>>> cl). There is no MinGW/MSYS Python (at least as far as I know), so

>>> that's not an option.

>> 

>> Yes there exist not "msys-python", you should use the native python package.

>> I use Scons Windows installer with the native python.

>> 

>>> Also, it's easier to run native SCons from a Cygwin shell than I

>>> thought: you just have to explicitly say 'scons.bat' instead of just

>>> 'scons'.

>> 

>> You're right, but there is a little problem on Cygwin. Cygwin uses always its

>> cygwin.dll, so each programm / library, that is compiled under Cygwin is linked

>> to this DLL. I can disable with -mo-cygwin this linking option, but some library like

>> Atlas & LAPack does not work anymore. On the dll exists also a licence, that are

>> added to the compiled programs, so in some cases Cygwin can make some problems.

>> Hence I would like to add also a naitive toolset for building my project. I need also the

>> autotools & make, so I must use MSYS / MinGW.

>> 

>> I run my scons build script on OSX 10.5 - 10.8, different Linux (Gentoo, Mint, Ubuntu) and Windows (Cygwin & MSYS),

>> so can I send the environment detection to this list, I think someone else can use this

> 

> 

> Let me summarize what I get from you emails:

> 1) You want to build using the mingw compiler/linker/etc on win32

> 2) you need your commands to be executed by a bourne shell (preferably msys's)

> 3) You have some third party libraries which build with configure,make,make install which you also need to build with MSYS/MINGW

> 4) You are using the normal win32 or win64 native python (not cygwin's)

> 5) You explicitly don't want to use the cygwin toolchain (at least for compiling/linking)

> 6) You're current main issue is when SCons shells out to run a command it's mixing cmd.exe flags with using sh.exe

> 

> Anything else?


Yes.  I have at the moment a working Scons solution, the information to the env["spawn"] call works with a manual set of the 
env["shell"] variable. In short I do this in the main Scons script:

envmingw.Tool("mingw")
from SCons.Platform.win32 import exec_spawn
from SCons.Platform.posix import escape
envmingw["SHELL"]     = "c:\\mingw\\bin\...\sh.exe"
envmingw["SPAWN"]     = (lambda sh, esc, cmd, args, envparam : exec_spawn([sh, "-c", escape(" ".join(args))], envparam))

This allows to run with env.command the commando on the sh mingw shell. The escape call of the posix scons is needed, because otherwise some commands
create errors, because the character masking. 

In this solution a env.Program does not work anymore, because the compiler command is not seperated the correct pathes. So I use two different Environment objects
a "default" env, which only uses the tool "mingw" and another with a seperated shell & spawn call (envmingw), so I can use mingw with a correct shell access.