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: [email protected] [mailto:[email protected]] 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 ([email protected]):
> 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 ([email protected]):
>
> > 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
> > [email protected]
> > http://two.pairlist.net/mailman/listinfo/scons-dev
>
> --
> Eric W. Anderson Electrical and Computer Engineering
> [email protected] 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
> [email protected]
> http://two.pairlist.net/mailman/listinfo/scons-dev
--
Eric W. Anderson Electrical and Computer Engineering
[email protected] 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
[email protected]
http://two.pairlist.net/mailman/listinfo/scons-dev
