[Scons-dev] Binding Environments to Nodes

[Kenny, Jason L]

I don't believe you have this correct.

A Node in SCons has a reference to environment that created it.

So as I understand it and have seen it work a call like:

F=File("foo")
 Will have a f.env that point to the DefaultEnvironment() active at the time it was called ( ideally SCons makes only one default environment, but there are way you might have this get re-created)

While 

Env=Environment()  
f=Env.File("foo")
f.env now is a reference to the env variable.

Keep in mind that I found that this might not be the same environment that the builder would use to do the actions to create the node.

I should point out the node.env is not a documented API.. so it could break at some point. ( not any time soon)

Jason


-----Original Message-----
From: scons-dev-bounces at scons.org [mailto:scons-dev-bounces at scons.org] On Behalf Of Eric W. Anderson
Sent: Wednesday, September 19, 2012 1:10 PM
To: SCons developer list
Subject: [Scons-dev] Binding Environments to Nodes

It doesn't seem like anyone else is especially fired up about this, which is OK.  There's one technical point on which I'd really like suggestions:

I'd like to have the/a user-constructed environment associated with nodes when Node.visited() is called.  As I understand it, that can (and often does) happen outside the context of any particular Builder, meaning that the only environment available is the DefaultEnvironment.  Since I want to allow user customization of what happens at that time, it makes sense to do that through a user-constructed Environment.

Any suggestions?  I don't know the inner workings of SCons well enough to have a great idea at this point.

Thanks,
Eric

Thus spake Eric W. Anderson (andersoe at ece.cmu.edu):


> Hi Jason (and list),

> 

> To be clear, I'm not proposing that that particular signature function 

> should become part of SCons.  What I want to add to the "core" SCons 

> code is the necessary set of hooks to accept and run user-supplied 

> signature-generating functions.  Indeed, the whole point is to allow 

> users to supply something which we wouldn't want _in general_, but is 

> right for their needs.  I see this as the missing half of the 

> user-specified Decider: You can write a much broader range of 

> functions if you can ensure that whatever information your decider needs has been gathered.

> 

> In my particular situation, the build tools themselves cause 

> "spurious" changes to the source files.  Unless those changes are 

> somehow filtered out, the files are _always_ changed, so a false 

> rebuild occurs every single time.  That's mostly an issue of poor tool design, but I'm stuck with it.

> 

> -Eric

> 

> Thus spake Kenny, Jason L (jason.l.kenny at intel.com):

> 

> > Interesting idea. However here are some cons to consider.

> > 

> > 1) this will take longer to process ( increase startup time) as one 

> > has to parse the file for a certain type of comment(s)

> > 2) a number of tools process values that are in the comments

> > 

> > In your case you point out how a comment that is updated by a VCS tool with a value of a new date, etc can cause a false rebuild of the code. That same value can be used by another tools to make documentation updates, or define many other values. Maybe in your case this is not so. You are suggesting that we have a tool based MD5 for a given node... i.e. I want a MD5 only of the content that the tool cares about, which could be one or more different signature per node.

> > 

> > Jason

> > _______________________________________________

> > Scons-dev mailing list

> > Scons-dev at scons.org

> > http://two.pairlist.net/mailman/listinfo/scons-dev

> 

> -- 

> Eric W. Anderson                     Electrical and Computer Engineering

> andersoe at ece.cmu.edu                          Carnegie Mellon University

> phone: +1-412-268-1908                                  Roberts Hall 244

> 

>                           PGP key fingerprint:

>        	   D3C5 D6FF EDED 9F1F C36D  53A3 74B7 53A6 3C74 5F12





> _______________________________________________

> Scons-dev mailing list

> Scons-dev at scons.org

> http://two.pairlist.net/mailman/listinfo/scons-dev



-- 
Eric W. Anderson                     Electrical and Computer Engineering
andersoe at ece.cmu.edu                          Carnegie Mellon University
phone: +1-412-268-1908                                  Roberts Hall 244

                          PGP key fingerprint:
       	   D3C5 D6FF EDED 9F1F C36D  53A3 74B7 53A6 3C74 5F12