You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by "Peter B. West" <pb...@powerup.com.au> on 2003/07/04 04:09:36 UTC
Build environment for alt.design
Fopdevs,
I am in the process of giving alt.design an Ant build environment, based
on the HEAD environment, with a number of significnt changes.
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.
This is primarily to ease the introduction to the code for newcomers,
but also to rationalise the basic working environment for development.
I will create a parallel src/codegen environment under src for the
repository. E.g. src/codegen/java. This will be easily usable in IDEs,
by adding the directory to the source path.
Code generation will always be a separate step, on the principle that
changes to generated code are infrequent. This violates another
principle - always build from the actual source of the files - but I
have always considered on-the-fly xsl code generation (and ant
copy-filtering) to be an abomination and a barrier to understanding.
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.
This implies a separate target for codegen, and I would include one for
codegen+cvscommit.
* Enforcing tag checkout for distribution builds
Some time ago I modified Version.java to take its version information
from the $Name$ keyword containing the Tag value. $Name$ is only set in
a file which is checked out using a specific tag, so in most cases in
the development environment, it will simply look like "$Name: $". In
those cases, Version.java provides a default value.
I have just extended Version to include a main which prints property
setting strings to stdout. The properties vary depending on whether a
real Tag value is available. The eventual aim is to have a distribution
build optionally detect the fact that no Tag is set, and to the perform
a complete checkout of the source with a given Tag, then perform a
sub-build of the distribution in that directory, guaranteeing that the
distribution is reproducible from the Tag. Note that the generated file
are also tagged, so there is no need to re-generate here, but a cvs diff
check would be prudent.
I'll post as I get pieces of this working, so that if any of it sounds
interesting for HEAD, curious parties can look at the results in alt.design.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Build environment for alt.design
Posted by Victor Mote <vi...@outfitr.com>.
Ralph LaChance wrote:
> At 12:20 PM 7/4/2003, you wrote:
> >[Happy Independence Day, fellow Americans!]
>
> and I always like to remind fellow Americans that
> the British call this "Thanksgiving Day"...
Yep, and we're thankful for Washington et al who made them thankful :-)
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Build environment for alt.design
Posted by Ralph LaChance <Ra...@compuserve.com>.
At 12:20 PM 7/4/2003, you wrote:
>[Happy Independence Day, fellow Americans!]
and I always like to remind fellow Americans that
the British call this "Thanksgiving Day"...
' Best,
-Ralph LaChance
In theory, there is no difference between
theory and practice, but in practice there is.
(Jan L.A. van de Snepsheut (1953-1994), late of CalTech)
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Build environment for alt.design
Posted by Glen Mazza <gr...@yahoo.com>.
OK, if it helps you and if you suspect it will help
others understand the system better, perhaps not such
a bad idea.
Glen
--- "Peter B. West" <pb...@powerup.com.au> wrote:
> Glen,
>
> 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.
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Build environment for alt.design
Posted by "Peter B. West" <pb...@powerup.com.au>.
Glen,
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" <pb...@powerup.com.au> 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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Build environment for alt.design
Posted by Glen Mazza <gr...@yahoo.com>.
[Happy Independence Day, fellow Americans!]
--- "Peter B. West" <pb...@powerup.com.au> 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.
> 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?
"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.
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.
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.
> 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.
Glen
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org