Re: Some comments on the build system
Keiron, Here's how the RCS works. $ rlog names RCS file: names,v Working file: names head: 1.2 branch: locks: strict access list: symbolic names: Rel_1: 1.1.1.2 RC1: 1.2.1.3 Rel: 1.1.1 Dev: 1.2.1 Base: 1.1 keyword substitution: kv total revisions: 7; selected revisions: 7 description: $Name$ test revision 1.2 date: 2002-04-10 08:10:16+10; author: pbw; state: Exp; lines: +3 -3 branches: 1.2.1; *** empty log message *** revision 1.1 date: 2002-04-10 08:08:33+10; author: pbw; state: Exp; branches: 1.1.1; Initial revision revision 1.1.1.2 date: 2002-04-10 08:36:59+10; author: pbw; state: Exp; lines: +2 -2 Release 1 revision 1.1.1.1 date: 2002-04-10 08:28:33+10; author: pbw; state: Exp; lines: +3 -3 Release branch revision 1.2.1.3 date: 2002-04-10 08:26:22+10; author: pbw; state: Exp; lines: +3 -3 Release candidate revision 1.2.1.2 date: 2002-04-10 08:13:13+10; author: pbw; state: Exp; lines: +2 -2 Churning... revision 1.2.1.1 date: 2002-04-10 08:11:44+10; author: pbw; state: Exp; lines: +3 -3 Development branch = Note the names Rel and Dev refer to branches; 1.1.1 and 1.2.1 respectively. So: $ co -rRel names names,v -- names revision 1.1.1.2 done $ cat names $Id: names,v 1.1.1.2 2002-04-10 08:36:59+10 pbw Exp $ $Name: $ 1.1.1.2 Note the empty Name keyword. co -rDev gives a similar result. But: $ co -rRel_1 names names,v -- names revision 1.1.1.2 done $ cat names $Id: names,v 1.1.1.2 2002-04-10 08:36:59+10 pbw Exp $ $Name: Rel_1 $ 1.1.1.2 fills in the blanks. However: $ co -r1.1.1.2 names names,v -- names revision 1.1.1.2 done $ cat names $Id: names,v 1.1.1.2 2002-04-10 08:36:59+10 pbw Exp $ $Name: $ 1.1.1.2 I.e., unless the actual revision you check out has a symbolic name AND you check it out using that name, the $Name$ keyword will be empty. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Some comments on the build system
This page has the cvs keywords: http://www.loria.fr/~molli/cvs/doc/cvs_12.html None of them seem to be useable for the version of a product. You still need to change something to make this update anyway. On 2002.04.05 00:44 Peter B. West wrote: Keiron, I don't know the nuts and bolts of CVS, but I always assumed that tags were somehow related to the RCS symbolic name, accessible via $Name$. $Name$ has some peculiarities due to the fact that there is not a unique name attached to the current version; I think it is set in the output files from the symbolic name under which the file is retrieved. I don't know, off hand, what the deault behaviour is. I can check the RCS characteristics here. Do you want to install $Name$ in one of the CVS files and see what it looks like when retrieved? Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Some comments on the build system
Keiron, As I suspected, $Name$ is the tag used to check out the file. In my maint checkout, I have a sticky CVS/Tag specifying fop-0_20_2-maintain (symbolic names cannot contain dot, because a revision is composed of one or more numeric or symbolic fields separated by periods - `man co'). Whenever I update, I am going to get that tag, and any $Name$ fields will contain that text. If the original conf/config.xml contains keyversion/key value$Name$/value I will actually see (given the default -kv flag to CVS) keyversion/key value$Name: fop-0_20_2-maintain $/value when I checkout or update. As I can't commit, I can't test this. Does it work that way? If so, the basis for providing the version string in the code is already in place. If that's unbearably ugly, add some code to Version.java to massage it. Symbolic names can contain any character except [0-9$@.;:], so there's plenty of room for establishing a conventional character to represent a space in the transformed output. E.g. FOP@0_20_2-maintain. I would be inclined to leave the underscores; I would be inclined to leave FOP-0_20_2-maintain untouched, just stripping off the keyword noise. $State$ is also available, but seems to require a cvs admin -s. What about HEAD? Just set a sticky tag of, say, FOP-1_0dev for commits, and notify that development checkouts must use this tag. If somone forgets when checking out, I don't think it's critical for development, as long as the commits use the tag. Releases will be frozen with the appropriate release tag, e.g., FOP-0_20_2-RC3, as I assume is currently done using rtag. Peter Keiron Liddle wrote: This page has the cvs keywords: http://www.loria.fr/~molli/cvs/doc/cvs_12.html None of them seem to be useable for the version of a product. You still need to change something to make this update anyway. On 2002.04.05 00:44 Peter B. West wrote: Keiron, I don't know the nuts and bolts of CVS, but I always assumed that tags were somehow related to the RCS symbolic name, accessible via $Name$. $Name$ has some peculiarities due to the fact that there is not a unique name attached to the current version; I think it is set in the output files from the symbolic name under which the file is retrieved. I don't know, off hand, what the deault behaviour is. I can check the RCS characteristics here. Do you want to install $Name$ in one of the CVS files and see what it looks like when retrieved? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Some comments on the build system
Arved, Obviously, I share many of your attitudes to properties, but I differ in one respect. I think of properties not as rich, but as impoverished. To me, they are just associations of names with values. The richness lies in their treatment in the process of layout, where all of those constraints and interactions will have to be accommodated and resolved in the application of properties to FOs and areas. Interactions, e.g., are inherently outside any individual property. Constraints, I have to admit, are generally property-centric, even where they involve testing the value of other properties. This view underlies my attempt to reduce property handling to a set of arrays. I still have an individual (though nested) class for each property, from which commonalities are extracted, while special cases are handled by methods peculiar to the class. Your concerns (and mine) about the association of build.xml release number and the tag would be resolved by making them identical, or at least deriving the first from the second. If my understanding of the relationship between RCS and CVS is correct, we can do this. Peter Arved Sandstrom wrote: Hi, Peter I personally agree that the properties don't need the XML+XSLT approach. Even if one leaves aside the aural properties there are over 250 properties, and on close inspection the commonalities are limited. I believe the largest group size of properties that are identical is 4. Many properties have extra constraints (they interoperate with other properties, for example), they accept different combinations of input generic types, percentages have meaning only in the context of the property, and so on and so forth. One could come up with a super-sophisticated XML+XSLT system to embody all this, but why bother? I'm not going to bad-mouth the current system that FOP has. I acquiesced at least implicitly in the choice to at least continue with it, at an early stage. But I now believe that the right place for a lot of logic related to properties is actually in the properties. I think an XML+XSLT approach pushes a lot of that out into places where it ought not to be. Most of the common handling has actually little to do with the properties per se - it has to do with expressions and datatypes. This is not the same thing. An XSL property is not a datatype, IMO, and shouldn't be regarded that way. I don't think it's a pressing issue unless someone then immediately proposes and moves forward with work to make the properties rich, interesting things. It's not really an IDE issue - there are IDEs that handle the current FOP setup just fine. I also agree that ease of making changes to properties is not a compelling argument for XML files, nor for using XSLT to generate the code. The properties are simply not that similar. So you may as well work on Java properties files directly. And since properties _are_ what make XSL, if there are significant changes in properties in the spec then the disruption is going to be widespread. I agree with Keiron's observations regarding the other point, about versioning. Our numbers are release numbers (major, minor, patch, plus stage info, as he puts it), and these require human decision-making. You can't automate release numbers sensibly. Anything else Ant supports (timestamping, token filtering, build number incrementing) makes a lot of sense in the right contexts, mostly in the sense of configuration management and builds. I'd like to see a stronger link between the release number in the build.xml and the presence of a matching tag in the CVS, myself. I've been personally guilty of forgetting to tag the CVS when buildng a distro and it's because there was no mechanism to jog my memory. I don't think the tagging itself should be automated but some aspect of the source code retrieval prior to building a dist* target should be dependent on the presence of a matching tag. Let's face it, right now we have no configuration management at all - maybe this isn't much better but at least it's something. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Some comments on the build system
Hi, Peter
I personally agree that the properties don't need the XML+XSLT approach.
Even if one leaves aside the aural properties there are over 250 properties,
and on close inspection the commonalities are limited. I believe the largest
group size of properties that are identical is 4. Many properties have extra
constraints (they interoperate with other properties, for example), they
accept different combinations of input generic types, percentages have
meaning only in the context of the property, and so on and so forth.
One could come up with a super-sophisticated XML+XSLT system to embody all
this, but why bother?
I'm not going to bad-mouth the current system that FOP has. I acquiesced at
least implicitly in the choice to at least continue with it, at an early
stage. But I now believe that the right place for a lot of logic related to
properties is actually in the properties. I think an XML+XSLT approach
pushes a lot of that out into places where it ought not to be.
Most of the common handling has actually little to do with the properties
per se - it has to do with expressions and datatypes. This is not the same
thing. An XSL property is not a datatype, IMO, and shouldn't be regarded
that way.
I don't think it's a pressing issue unless someone then immediately proposes
and moves forward with work to make the properties rich, interesting things.
It's not really an IDE issue - there are IDEs that handle the current FOP
setup just fine.
I also agree that ease of making changes to properties is not a compelling
argument for XML files, nor for using XSLT to generate the code. The
properties are simply not that similar. So you may as well work on Java
properties files directly. And since properties _are_ what make XSL, if
there are significant changes in properties in the spec then the disruption
is going to be widespread.
I agree with Keiron's observations regarding the other point, about
versioning. Our numbers are release numbers (major, minor, patch, plus stage
info, as he puts it), and these require human decision-making. You can't
automate release numbers sensibly.
Anything else Ant supports (timestamping, token filtering, build number
incrementing) makes a lot of sense in the right contexts, mostly in the
sense of configuration management and builds.
I'd like to see a stronger link between the release number in the build.xml
and the presence of a matching tag in the CVS, myself. I've been personally
guilty of forgetting to tag the CVS when buildng a distro and it's because
there was no mechanism to jog my memory. I don't think the tagging itself
should be automated but some aspect of the source code retrieval prior to
building a dist* target should be dependent on the presence of a matching
tag. Let's face it, right now we have no configuration management at all -
maybe this isn't much better but at least it's something.
Regards,
Arved
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]]
Sent: April 3, 2002 12:23 PM
To: fop-dev
Subject: Some comments on the build system
Fops,
I would like to see the build system overhauled. The overall objectives
of the overhaul would be to simplify the build process and decrease
barriers to entry for would-be developers. The tactical objectives
would be to eliminate XSL from the build, and to generate the classes
directly from the source tree. The advantages of this approach are, I
think, obvious. For a developer using an IDE/JDE, the source tree
associated with the classes whose behaviour is being observed would be
the same source tree to which changes are being made, and the same
source tree from which commits would be made. Eliminating XSL, and
expressing the system entirely in Java means that, as far as development
is concerned, what you see is what you get. There are no invisible
shenanigans going on behind the build.
I have not gone over the XSL with a fine-toothed comb, but what I have
seen is enough to be able to give the flavour of the argument.
Basically, if you feel the need to generate Java from a combination of
XML and XSL, you should make your Java look more like your XML, and less
like the output from your XSL. The neat data characteristics of the XML
can and should be expressed more or less directly in Java.
Font generation is simple to translate into a static reference HashMap
from names to codepoints, set up with a static{} block, and some further
static{}s to set up the width arrays.
Properties are a fascinating topic. To me, the fact that Properties
virtually demand some kind of code generation is proof enough that the
approach is wrong. But more of that another time. Let's say that you
do need some help to set these things up. How many times do you need to
do it? Isn't once enough? The majority of the class files having been
set up, what varies?
Create the base files, and check them in to CVS. Then put the XML and
XSL aside as a once-useful historical oddity. Unimplemented properties
Re: Some comments on the build system
Keiron, I don't know the nuts and bolts of CVS, but I always assumed that tags were somehow related to the RCS symbolic name, accessible via $Name$. $Name$ has some peculiarities due to the fact that there is not a unique name attached to the current version; I think it is set in the output files from the symbolic name under which the file is retrieved. I don't know, off hand, what the deault behaviour is. I can check the RCS characteristics here. Do you want to install $Name$ in one of the CVS files and see what it looks like when retrieved? Peter Keiron Liddle wrote: On 2002.04.03 18:23 Peter B. West wrote: There are a couple of other things which encourage the separation of source and build.source trees. They involve the use of copy filtering in ant. Version information is, I think, supplied by ant via the build.xml file. This vile and disgusting habit, which ant seems to encourage, should be stamped out at once. Version information comes from the version control system in use at the time, not from hand-hacking on build.xml. A few changes to Version.java to massage the output of the RCS macros are all that is needed. If that massaging is required during the build itself, an ant task should be able to do it. I don't quite see how you could use RCS to set the version. The information will only update if something is checked in, what will be changed in the file to check it in? Do you really want the versions to count up 1.[0..n], how do you specify bug, minor and major releases, what about stages ie. dev, alpha, beta, final. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Some comments on the build system
Fops,
I would like to see the build system overhauled. The overall objectives
of the overhaul would be to simplify the build process and decrease
barriers to entry for would-be developers. The tactical objectives
would be to eliminate XSL from the build, and to generate the classes
directly from the source tree. The advantages of this approach are, I
think, obvious. For a developer using an IDE/JDE, the source tree
associated with the classes whose behaviour is being observed would be
the same source tree to which changes are being made, and the same
source tree from which commits would be made. Eliminating XSL, and
expressing the system entirely in Java means that, as far as development
is concerned, what you see is what you get. There are no invisible
shenanigans going on behind the build.
I have not gone over the XSL with a fine-toothed comb, but what I have
seen is enough to be able to give the flavour of the argument.
Basically, if you feel the need to generate Java from a combination of
XML and XSL, you should make your Java look more like your XML, and less
like the output from your XSL. The neat data characteristics of the XML
can and should be expressed more or less directly in Java.
Font generation is simple to translate into a static reference HashMap
from names to codepoints, set up with a static{} block, and some further
static{}s to set up the width arrays.
Properties are a fascinating topic. To me, the fact that Properties
virtually demand some kind of code generation is proof enough that the
approach is wrong. But more of that another time. Let's say that you
do need some help to set these things up. How many times do you need to
do it? Isn't once enough? The majority of the class files having been
set up, what varies?
Create the base files, and check them in to CVS. Then put the XML and
XSL aside as a once-useful historical oddity. Unimplemented properties
will presumably be implemented one at a time, so it will be no hardship
to create the class file by hand, and check the changes in. If some
global-ish change needs to be made, a perl one-liner will probably do
it, and you check the changes in. The same considerations apply to
fonts if you are really, really committed to XML/XSL. However, with
fonts, I understand that user font data in XML is read in at
configuration time. If so, why not read the system font data as well?
There are a number of ways to skin this particular cat, none of which
leave you with a three-language source base. Three languages which have
the annoying characteristic of morphing into one, under the hood.
There are a couple of other things which encourage the separation of
source and build.source trees. They involve the use of copy filtering
in ant. Version information is, I think, supplied by ant via the
build.xml file. This vile and disgusting habit, which ant seems to
encourage, should be stamped out at once. Version information comes
from the version control system in use at the time, not from
hand-hacking on build.xml. A few changes to Version.java to massage the
output of the RCS macros are all that is needed. If that massaging is
required during the build itself, an ant task should be able to do it.
The other one may be more difficult. I haven't looked at it in detail,
or recently, but the copy-filtering was being used to accommodate, I
think, TRaX variations. How difficult that would be to work around I
don't know.
The bottom line is a general increase in sanity, and the simplification
and unification of the build, development and testing environments.
Your obsequious servant,
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Some comments on the build system
On 2002.04.03 18:23 Peter B. West wrote: There are a couple of other things which encourage the separation of source and build.source trees. They involve the use of copy filtering in ant. Version information is, I think, supplied by ant via the build.xml file. This vile and disgusting habit, which ant seems to encourage, should be stamped out at once. Version information comes from the version control system in use at the time, not from hand-hacking on build.xml. A few changes to Version.java to massage the output of the RCS macros are all that is needed. If that massaging is required during the build itself, an ant task should be able to do it. I don't quite see how you could use RCS to set the version. The information will only update if something is checked in, what will be changed in the file to check it in? Do you really want the versions to count up 1.[0..n], how do you specify bug, minor and major releases, what about stages ie. dev, alpha, beta, final. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
