[Scons-dev] Binding Environments to Nodes

[Eric W. Anderson]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
Url : <http://two.pairlist.net/pipermail/scons-dev/attachments/20120919/93eeac30/attachment.pgp>