[Scons-users] Setting environment variables for scons to use globally on my system
    Benjamin Lindley 
    benjameslindley at gmail.com
       
    Thu May 15 08:23:05 EDT 2014
    
    
  
On 5/15/2014 5:01 AM, Russel Winder wrote:
> On Thu, 2014-05-15 at 04:31 -0500, Benjamin Lindley wrote:
>> That will probably help, if I can figure out one more thing. This is
>> more of a Python question though, so sorry if it's off topic (but maybe
>> there's a scons specific answer). I guess I need to figure out how (if
>> it's even possible) to change the default arguments to the Environment
>> constructor. So, for example, if the SConstruct file has this:
>>
>> env = Environment()
>>
>> I want it to be as if it says this:
>>
>> env = Environment(tools = ['mingw'])
>>
>> Thanks for the help.
> You are probably looking at having a "feature variable". I am not a fan
> of command line options when working with SCons, so I tend to write in a
> local.build.scons file (or some such)
>
> local.build.scons:
>
> 	tool_chooser = False
>
> Then in the SConstruct:
>
> 	tool_chooser = True
>
> 	with open('local.build.scons') as f:
> 	    exec(f.read().strip())
>
> 	…
>
> 	if tool_chooser:
> 	    env = Environment(tools = ['mingw'])
> 	else:
> 	    env = Environment()
>
> then the SConstruct is programmed with the options and a default, and
> the local file contains the selector that needs to be edited.
>
> It's not a great solution, but it works.
>
No, that does not solve my problem, unless I can count on everybody 
creating their SConstruct files like that. The point is to have a build 
system where the person writing the build file does not need to have any 
concern about what tool-chain is being used. I will describe a 
hypothetical situation, perhaps that will help.
You create a program, written in portable C++. You use SCons as your 
build system. You successfully compile and run it on your system, let's 
say you use Linux with GCC. But you don't use any specific 
configurations, just the default Environment(). That works fine for you, 
because GCC is what SCons assumes on Linux. You upload the source code, 
along with the build files onto GitHub. I fork the project on my Windows 
machine. I try to build it, and it fails because it assumes, because I'm 
on Windows, that I want to use VC++. But I don't have VC++ installed. I 
use MinGW. I can fix this problem, but I have to modify the SConstruct 
file, telling it to use MinGW, and also telling it the path where my 
MinGW installation can be found. The project is now tailored very 
specifically to my system setup, oddly containing references to paths 
which are only applicable to my filesystem.
This is all wrong, in my opinion. What I would like to be able to do is 
create SCons projects which contain no references to tool-chains or 
their locations. In my own environment, separate from my projects, I 
should be able to determine things such as which compiler to use for 
C++, rather than having SCons make an assumption for me. The assumptions 
are fine to be used by default, but I should have some way to override 
them globally, without specifying it in every project I make. And then 
when I download someone else's project, as long as it is written in 
portable C++, I should be able to build it right away without making any 
modifications. Isn't that how a cross platform build system is supposed 
to work?
    
    
More information about the Scons-users
mailing list