Comments below, but to preface, let me say that alt.design has not had an Ant build system to date, so there is no penalty in my doing things differently, because I have to hack the build.xml anyway. What I do does not impact on HEAD, and provides a testbed for examining a different approach.
Glen Mazza wrote:
[Happy Independence Day, fellow Americans!]
--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
The basic build principles that I will implement include:
* No code generation or modification for normal builds. * All generated code and data maintained in CVS.
I don't think you have to bother with this. This is akin to storing binaries in CVS--kind of messy.
Not at all. Code generation is kind of messy; well, very messy, and very confusing. I understand the counter-argument, but I disagree with it. This is a Java system, and the source is Java. I just want that source immediately available.
This is primarily to ease the introduction to the
code for newcomers, but also to rationalise the basic working
environment for development.
But Peter--isn't the developer IQ & work ethic required to constructively help on FOTreeBuilding, Area Tree/Layout, Rendering, etc. far greater than whatever would be needed to understand automatic code generation?
Yes. But....
"I am too stupid & lazy to look into build/src for
autogenerated code" but "Hey, FOP Team, let me help
you out on that Area Tree redesign you have there" is
a contradiction.
Glen, this makes me very uneasy. If anyone who finds the code generation system opaque is stupid, then I am stupid. If being put off delving into it by the opaqueness is laziness, then I am lazy. I put it off for as long as I possibly could. I know you're not saying that, but I, for one, like to know what is going on with the code I get involved with. I don't like the feeling that code is being conjured up as if by magic, and I find that off-putting.
As a relative newcomer, I can tell you--There is a
*ton* of FOP I still don't understand--Area Tree
creations, fonts, Renderer's etc. (and *feel free* to
make that more understandable!) But this has 0.00% to
do with autogenerated code.
I don't claim that it does. I am simply saying that, in itself, it is an obscure area of the system.
Rather, I just haven't gotten to those areas of code yet, also I wouldn't be surprised if "cerebral limitations" also kick in more than I would like along the way. So with every other potential developer.
... I don't see Open Source development as a trial by fire. I don't care about developer IQ or work ethic. Any contribution which is a nett benefit to the project is welcome. I want to make such contributions more feasible, rather than less. In any case, I have often found that those who are most diffident about their ability display plenty of it when encouraged.
Once the code generation step is separated, normal
builds can monitor the state of the generated code by a) checking
creation dates of generated files and their sources and b) performing
cvs diffs against the repository. For a normal build, I would simply
check timestamps, while for a distribution build I would enforce a
repository check.
In the normal case, inconsistencies in the generated
code would halt the build. A property could be defined to override this
from the command line or from build-local.properties.
All this to avoid a minute or two of extra build time?--it doesn't seem worth the headache.
No, it's not to avoid a small increment of build time. If basic checks of generated code consistency actually took longer, I would still do it. The purpose is to have the Java code from which the system is built available on checkout. The code generation is a background tool for intermittent use only, and should be invoked only for the specific occasional purpose of generating new code (or data) files for the system.
Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
