<br><tt><font size=2>testtools-bounces@list.coin-or.org wrote on 01/16/2009
07:51:48 AM:<br>
<br>
> Gents,<br>
> <br>
> JP and I have been exchanging emails about BuildDirSuffix,
and he's been<br>
> persistent enough to convince me that there's a possibility of accidental<br>
> persistence from one build to the next. I'm testing out a fix
(pop the value<br>
> from configuration if it's not specified for a given build). But
it<br>
> seems to me<br>
> the problem really lies in the way that the main loop of <br>
> nightlyBuild assembles<br>
> a configuration. We're in nightlyBuild.py.<br>
> <br>
> Where it says `Define loop invariant configuration values',
we<br>
> initialise a map (configuration) and a set of sets (configurations).
Prior to<br>
> entering the loop on projects, some persistent keys (rootDir,<br>
> buildMethod) are set in configuration, to be used by all projects.<br>
> <br>
> Now we enter the project loop (`Loop once for each project
...'). We<br>
> set two more keys, project and `clear previous build', to be used
<br>
> for all builds<br>
> of a project. (Arguably, `clear previous build' should be handled
as a <br>
> persistent key, since it's initialised from a global variable.)<br>
> <br>
> Now we enter the build loop, processing the builds specified
for the<br>
> project. We fill in a whole bunch more keys in configuration. Eventually,
we<br>
> check to see if configuration is already in configurations. If not,
<br>
> we process <br>
> it (NBbuildConfig.run) and record it in configurations.<br>
> <br>
> Now, it seems to me that at this point the logical thing
to do is clear<br>
> configuration back to an empty map and start over to fill in configuration
for<br>
> the next build, but that doesn't happen. The consequence is
that once a<br>
> key:value pair is added to configuration, it persists until explicitly
removed<br>
> or changed. This is not safe. I'd like to propose something
a bit different,<br>
> but fairly close to what now exists.</font></tt>
<br>
<br><tt><font size=2>Sounds like a prudent thing to do.</font></tt>
<br>
<br><tt><font size=2><br>
> <br>
> There are three classes of keys in a configuration: top-level
(for all<br>
> projects), project-level (for all builds of a project), and build-<br>
> level (for an<br>
> individual build). Right now, rootDir and buildMethod are handled
<br>
> as top-level,<br>
> project and `clear previous build' are handled as project-level, and
all the<br>
> rest are (or should be) handled as build-level.<br>
> <br>
> Why not make this explicit, by creating two new variables,<br>
> top_configuration and project_configuration. These get loaded
at the places<br>
> where top-level and project-level keys are processed now.<br>
> <br>
> Then, in the inner loop (`for bc in buildConfigs'), the
first action<br>
> is to clear configuration and load it with the values from <br>
> top_configuration and <br>
> project_configuration. This should prevent accidental carry-over.</font></tt>
<br>
<br><tt><font size=2>You have obviously studied and thought about the code
more than myself.</font></tt>
<br><tt><font size=2>From my perspective it sort of grew and had more things
patched into it (as I learned and experimented more with python).</font></tt>
<br>
<br><tt><font size=2>The changes you suggest are fine with me.</font></tt>
<br>
<br><tt><font size=2>If you would feel more comfortable not making bigger
changes trunk, feel free to make a copy in branches.</font></tt>
<br><tt><font size=2>I could then check out the branches and run a test
on the 4 platforms where I currently nightlyBuild.</font></tt>
<br><tt><font size=2>But I think it is OK to make changes in trunk.</font></tt>
<br><tt><font size=2>After all, there aren't many people using nightlyBuild.</font></tt>
<br><tt><font size=2><br>
> <br>
> Documentation and code comments should be updated to
reflect the three <br>
> classes of parameters. As an added benefit, the user could override
top-level <br>
> and project-level keys in a build configuration, should s/he so desire.</font></tt>
<br>
<br><tt><font size=2>More documentation is of course good.<br>
> <br>
> You guys will regret dragging me into this ...
:-)</font></tt>
<br>
<br><tt><font size=2>No & No.</font></tt>
<br><tt><font size=2>I most certainly don't regret it.</font></tt>
<br><tt><font size=2>I don't really think you feel dragged into this either
(at least I hope not).</font></tt>
<br>
<br><tt><font size=2><br>
> <br>
>
Lou<br>
> <br>
> _______________________________________________<br>
> Testtools mailing list<br>
> Testtools@list.coin-or.org<br>
> http://list.coin-or.org/mailman/listinfo/testtools<br>
</font></tt>