[Scons-users] Setting environment variables for scons to use globally on my system

[Björn Pollex]

On Thu, May 15, 2014 at 2:23 PM, Benjamin Lindley <benjameslindley at gmail.com

> wrote:



> 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?

>

> Well, any globals you create in site_init.py will be available in your

SConstruct. There are variaous ways you could use this to initialize a
portable environment.

Regards,

    Björn Pollex


> _______________________________________________

> Scons-users mailing list

> Scons-users at scons.org

> http://four.pairlist.net/mailman/listinfo/scons-users

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://four.pairlist.net/pipermail/scons-users/attachments/20140515/03d586d8/attachment.html