java/44041: Generate bsd.java.mk from an XML file

[Greg Lewis]

Hi Herve,

On Thu, May 01, 2003 at 06:48:36PM +0200, Herve Quiroz wrote:
> On Thu, 1 May 2003, Greg Lewis wrote:
> > On Thu, May 01, 2003 at 09:18:56AM +0200, Ernst de Haan wrote:
> > > Hi Herve,
> > >
> > > > I was in the mood for some XSLT coding so I decided to take care of this
> > > > one hour ago. So far, I've finished everything up to step 3 (included)
> > > > but I will need to get some sleep sooner or later ;)
> > > >
> > > > So I was wondering if you still need this XML->bsd.java.mk tool... and if
> > > > you (or anybody else) had already done something about it.
> > >
> > > Haven't done anything about it yet. And I personally think it's a very good
> > > idea. This way we only have to maintain a bsd.java.xml file.
> > >
> > > Greg, what do you think of this?
> >
> > Well, without having seen Herve's XSLT, I think the best way of explaining
> > things is to describe what I would like to see ultimately happen with
> > bsd.java.mk.  Maybe some of this is due to not fully understanding the
> > file, but here goes.
> > [...]
> >
> 
> Well, I was just working on the dependency stuff in stage 4 of the
> bsd.java.mk which is not simple to implement in XSLT. But maybe I should
> wait that we fix this before...
> 
> You're right bsd.java.mk sometimes behaves a strange way. And your
> "multiple JDK dependency" point is right if you take for example the
> jakarta-commons-logging port. It compiles and runs with any JDK (1.2+) but
> if you've got JDK 1.4, it's better because it also handles the 1.4 logger
> API.

Right.  So maybe in that case you prefer 1.4.  However, maybe some other
port works with 1.4 but exercises a bug in our 1.4 (for example) and you
want to prefer 1.3.

> So, the question is: what to do for now ? Let the bsd.java.mk as-is ? Have
> an XSLT to generate it from an XML Java VMs list ?

I still have some difficulty believing that this won't severely limit
what we can do in bsd.java.mk.  I realise XSLT is Turing complete, but
I really think we're asking for a lot of pain trying to generate
arbitrary Make and shell syntax from an XML file using XSLT.  At best
I think generating an included list of default preferences is workable, 
but I'd still prefer to generate that list from the ports themselves
to remove the maintenance issue entirely (all the XML proposal does is
move the maintenance to a different file and format).

> We could have a user/system configuration file to specify which JDKs/JREs
> to install and in which order, as it is the case for many applications
> (/usr/local/etc/pkgtools.conf, /etc/make.conf...). And to be
> "cutting-edge", we could use an XML file to store preferences instead of
> the standard Perl or Ruby stuff. XML processing has many dependencies but
> so does any Java port so this is not an issue.

But why XML?  This should be simple enough to be able to support just
environment settings (which could be standardly read from /etc/make.conf
or some other, similar file read by bsd.java.mk).  XML doesn't seem to
be a good fit and seems inconsistent with how ports preferences are
generally expressed.

Of course, the people prepared to do the work ultimately get to pick :)

-- 
Greg Lewis                          Email   : glewis at eyesbeyond.com
Eyes Beyond                         Web     : http://www.eyesbeyond.com
Information Technology              FreeBSD : glewis at FreeBSD.org