Well, the 'test' mode of autoconfig lasted exactly five hours yesterday until someone
inadvertantly committed an autogenerated version of modules.build.xml. :-) I'm not
surprised; I did it once myself.
Anyway, I've just committed changes to complete the integration of autoconfig into the
Version 7 build system. This has the following implications:
(1) After your next SVN update, your modules.build.xml file will disappear. After that,
the next time you try to build the system, it will immediately fail with an informative
error message that tells you that modules.build.xml was not found and to use 'ant -f
autoconfig.build.xml' to generate it. Do this and you should be back on your way.
(2) If a new hackystat module is added to SVN, the build system won't know about it until
modules.build.xml is regenerated. I currently have the build system do an uptodate that
checks the modules.build.xml file against all existing local.build.xml files. If
modules.build.xml is out of date relative to these files, a warning message is printed
but the build does not fail. This will generate false positives sometimes, and if it gets
too annoying I will make the uptodate check better.
(3) Each time you run autoconfig, you'll get a new version of
sample.hackystat.build.properties in your ${hackystat.base.dir}. This is a convenient way
to get a list of all hackystat modules. Rename it to hackystat.build.properties if you
want to build the complete system.
(4) The daily build is going to fail until the scripts are updated to run autoconfig each
day . Mike, could you edit the daily build scripts to run SVN update, then 'ant -f
autoconfig.build.xml', then 'ant freshStart all.junit' (or whatever)? The important
thing is that we regenerate a fresh version of modules.build.xml each day before starting
the build.
Let me know if/when you run into problems.
Cheers,
Philip
