[Scons-users] dependencies when you define environment variables

[TOM TANNER (BLOOMBERG/ LONDON)]

I think the emitter being allowed to alter the env would be a really excellent way to go. I'll stick in an enhancement request

----- Original Message -----
From: scons-users at scons.org
To: scons-users at scons.org
At:  7/19 15:50:04

On Thu, Jul 19, 2012 at 4:44 AM, TOM TANNER (BLOOMBERG/ LONDON)
<ttanner2 at bloomberg.net> wrote:

> On the whole, that (adding the thing to the builder /call/) is rather unfortunate as it means the client needs to know something of how the builder is implemented and it means if we replace a toolchain with another toolchain that behaves slightly differently we need to go and find all the clients thereof and replace the calls.

>

> Yes, I know I'm being picky. But my experience is that little things like that can trip people up and cause embarassing problems later on down the line, and hiding 'implementation details' like that would seem to be a good thing to do.


Not being picky at all.  What you say makes total sense; I was just
explaining what you can do today (vs. changes we could make in the
future).

I think what you'd like is for env[ENV] variable values to go through
the construction-variable substitution process, so you could set
env['ENV']['FOO'] to "$SOURCE abc" and it would dynamically pick up
the source each time the builder runs.  Maybe it could be enabled as
an option per-builder or something (we couldn't do it all the time,
since it would produce pretty odd results if you happen to have a $ in
any env var, and anyway it'd be slow).

As an alternative, what if emitters could alter the env's construction
vars the same way they modify the target and source lists?  That would
fill your need as well.

Could you submit an enhancement request to Tigris?

-- 
Gary
_______________________________________________
Scons-users mailing list
Scons-users at scons.org
http://four.pairlist.net/mailman/listinfo/scons-users