Date: Tue, 29 May 2001 12:46:06 -0700 From: Rich Morin <rdm@cfcl.com> To: ports@FreeBSD.ORG Subject: Re: XML-based ports system ? Message-ID: <p05001905b739a3d1c212@[192.168.168.205]> In-Reply-To: <20010528105709.A9284@c187104187.telekabel.chello.nl> References: <20010528105709.A9284@c187104187.telekabel.chello.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
I would be very happy to see the Ports Collection switch to an
abstract, declarative infrastructure. I like the idea of using
XML for this, mostly because of the number of tools that it has.
In line with this, I will take on some of Doug Barton's comments:
DB>what are the advantages to the declarative approach?
One of the big wins of the Ports Collection is that it is flexible;
if I want to change how it behaves, I can edit the base-level Make-
files (as Dr. Love has done in porting the collection to Mac OS X).
The flexibility is limited, however, by the encoding of imperative
notions (let alone explicit code) in the package-specific Makefiles.
A declarative format would allow greater flexibility in processing;
if I wanted to cross-reference the documents (or source code) in a
package, I could use the same "build" files with a different "make"
engine. More to the point, I recently found myself having to do a
cursory parse of system Makefiles, in order to determine where the
source code was actually stored for common commands (e.g., vi). I
would have been MUCH happier to have the information in XML format!
DB>Most of the new users we have lately have a hard enough time
DB>understanding simple instructions in plain english. Further
DB>obfuscating things with XML is unlikely to help.
It isn't the explanations that are being put into "plain english"
[sic]; it is the Makefiles. The syntax of Makefiles is arcane and
even rather silly in spots (why should tabs be treated differently
than spaces?). Worse, Makefile writers commonly embed code from
other languages (e.g., awk, sed, sh), creating something that only
a script wizard can parse. Finally, by putting the information in
XML, there is a reasonable chance that the information can be used
to drive automated analysis, forms-based interfaces, etc.
DB>There are many more tools for manipulating text files.
Yes and no. Unix has lots of tools for manipulating text files,
but they don't do much for analyzing Makefiles, shell scripts, or
even many control files (try parsing /etc/printcap in awk :-). In
contrast, I can use XMLin to import any well-formed piece of XML,
then walk through it as a Perl data structure.
I have used both Boulder I/O and XML as a way to encode control
files, serialize data structures, etc. The ability to create
human-readable (and -editable, if need be) data files is quite
useful, even when there isn't a DTD within miles...
BTW, I was pleased to hear Jordan Hubbard say (at Apple's WWDC 2001)
that he was considering the idea of replacing the Ports Collection's
Makefile infrastructure with XML...
-r
P.S. For a more extended discussion of these and related issues,
see the Meta Project (http://www.cfcl.com/Meta).
--
http://www.cfcl.com/rdm - home page, resume, etc.
http://www.cfcl.com/Meta/md_fb.html - The FreeBSD Browser
email: rdm@cfcl.com; phone: +1 650-873-7841
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05001905b739a3d1c212>