---------- Forwarded message ----------
From: Christoph Lofi <[EMAIL PROTECTED]>
Date: Sep 13, 2005 10:22 AM
Subject: Re: [HACKYSTAT-DEV-L] RFC: modularized build process
To: Philip Johnson < [EMAIL PROTECTED]>
Hi!
I think this approach is very nice as it solves the problem and can be implemented very easily (as far as I see):
My first suggestion to that is just taking the old build files and convert them to a template file for template engines like velocity or freemarker. The only other things you need is the "crawler" scanning for the module configuration files and some kind of dependency checker (checking if all required dependencies are present).
I am pretty sure that there are more radical, and maybe more powerful ways to solve the problem. But this one is, I think, the easiest and most compatible one (as you can just keep manual build files if necesarry).
If you want I can give that thing a try (shouldn't be too hard, I guess).
Cheers,
Christoph
On 9/13/05, Philip Johnson <[EMAIL PROTECTED]
> wrote:
Greetings, all,
As part of the Version 7.0 release planning, I wanted to try to address a build issue
that has bugged me for a long time.
Consider the situation of someone who wants to develop their own Hackystat module
(hackyFoo) and build a local version of the system with their hackyFoo extension
incorporated. Currently, that process is (a) difficult and (b) undocumented.
Essentially, you have to hack our build.xml file in several places:
- The "checkModuleAvailability" task must be hacked to check for the availability of the
new hackyFoo module.
- A new "doInternal_hackyFoo" task must be written for the new module, indicating its
dependencies on other modules.
- The "doAll" task must be hacked to include the new "doInternal_hackyFoo" task.
Of course, each time we release a new version of Hackystat, with possible changes to the
build.xml, the person who has implemented hackyFoo has to go in and manually edit the new
build.xml to include the hackyFoo changes.
This is totally bogus. The basic problem is that our build.xml file, as currently
written, hard-wires in knowledge about all of the known modules for Hackystat. What we
really need is a build.xml file that "discovers" the set of Hackystat modules at Ant
invocation time. Consider the following idea:
Right now, each module must include its own local.build.xml file, which provides
module-specific tasks to support compilation and installation. This is A Good Thing and
works very well. Let's extend this to say that each module also needs to include a
local.module.definition.xml file, which might look like this:
<hackystat-module>
<name>hackyFoo</name>
<available>on</available>
<dependent-modules>
<module>hackyKernel</module>
<module>hackyStdExt</module>
</dependent-modules>
</hackystat-module>
As you can see, a module definition is simple: it just specifies the module name, whether
it is "available" (this replaces the hackyFoo.available property in
hackystat.properties), and what modules it depends upon (this replaces all of the
information now hard-wired into build.xml).
Now, let's apply the "autoconf" pattern to the problem. A simple way to solve things
would be to say that when someone wants to build Hackystat for the first time with a new
or changed module definition, one must do:
ant config
what that does is search all of the "sibling" directories to hackyBuild, looking for
occurrences of local.module.definition.xml files. When it finds them, it reads in the
data, and uses that information to _generate_ a build.xml file that includes the
checkModuleAvailability, doInternal_<module>, and doAll tasks with all known modules.
At this point one can invoke all of the normal set of commands. Furthermore, each time
one runs a "normal" command, there is first a quick check of the timestamps associated
with all known local.module.definition.xml files, and if their timestamps are later than
the timestamp associated with build.xml, then the invocation fails with a notice that the
developer needs to re-run 'ant config' to get an up to date version of build.xml .
This particular scheme seems quite feasible to me, since it requires no changes to the
current build process other than the creation of a "configuration" step.
Questions for discussion:
- There might be ways to simplify the resulting build.xml file by using recent ant
features like macrodefs and so forth.
- Is there a more radical way to re-invent the build process to accomplish this same goal?
I'd really like to get this fixed in the near future; I think it will significantly
simplify external involvement in hackystat development.
Let me know what you think.
Cheers,
Philip
