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
signature.asc
Description: Digital signature
_______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
