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

[Kenny, Jason L]

I would agree with Garry on this. This is not as simple as it looks.

I have tried to make some attempt at solving this with an add on to SCons called Parts.

In this system you can provide the toolchain and target you are wanting to build for on the command line. I also provide an idea of a toolchain ( a bit better than the default tool in SCons, but honestly it needs a little more work) that allows you to define what default chain of tools you would like on a given system, etc..

A simple of example of this would be the ability to say ( note Parts is an addon, so Scons still drives the build):

Scons <target> --toolchain=gcc_4.6 --target=android-x86

If no tool chain is given the system used the default tool chain is used, This works much like the default tool in SCons. However it currently is a bit more focused on c/c++ based toolchains than other languages at the moment, but it does try to fine the “best tool” given the system you are on.. You are free with this to define you own toolchains as well.

You are free to give it a try. I know it works well as it used on a number of project where I work at and seems to be spreading. Look at http://parts.tigris.org/ Maybe this will help you.

The other solution you can try that is pure SCons is to make a scons-site/tools directory and define you default.py tool. This could be shipped with the code so when you Sconstruct is being built it would be used. Given Parts I would have you do a similar thing with a part-site directory as well with for defining you own toolchain. I not sure if Scons has been updated with the idea to allow the scons-site to be in different locations, making it easier to apply a fix to development system to control what default tool is used or not. If not I have this logic in Parts, and I have a team or two that setup there system by installing at a user or system level a part-site directory with customization they desire for their build ( such as tool chain, custom tools, etc.).

Hope this helps.
Jason


From: scons-users-bounces at scons.org [mailto:scons-users-bounces at scons.org] On Behalf Of Gary Oberbrunner
Sent: Thursday, May 15, 2014 10:13 AM
To: SCons users mailing list
Subject: Re: [Scons-users] Setting environment variables for scons to use globally on my system



On Thu, May 15, 2014 at 8:23 AM, Benjamin Lindley <benjameslindley at gmail.com<mailto:benjameslindley at gmail.com>> wrote:
...
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?

Although I think your  local problem can probably be solved by monkey-patching the default tool list in a site-scons file, you've hit on a larger problem which is how to define, use and select by default "tool chains" in a sitewide way.  This is a project we're working on as part of redefining how tools are created and used.

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