Date: Wed, 30 May 2001 03:42:20 -0700 From: Doug Barton <DougB@DougBarton.net> To: Rich Morin <rdm@cfcl.com> Cc: ports@FreeBSD.ORG Subject: Re: XML-based ports system ? Message-ID: <3B14CE8C.AC8137A0@DougBarton.net> References: <20010528105709.A9284@c187104187.telekabel.chello.nl> <p05001905b739a3d1c212@[192.168.168.205]>
next in thread | previous in thread | raw e-mail | index | archive | help
Rich Morin wrote:
>
> 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!
You still haven't demonstrated quantitatively _how_ your proposed system
would be better. All you've basically said here is, "It would be easier for
me to work with if it were closer to what I already know." That's not meant
as a criticism of you as a person, I'm simply trying to get some hard data
to base a judgement on. We've seen lots of very technical-sounding
explanations as to why XML is better, what I haven't seen demonstrated is
how.
> 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.
You've quoted me way out of context here, but I'll take your points on at
face value.
> The syntax of Makefiles is arcane and even rather silly in spots
The exact same thing can very easily be said of XML markup. More so with a
bad DTD.
> (why should tabs be treated differently
> than spaces?).
This is one of those things that made sense at the time, but doesn't
necessarily now. Newer versions of make are more forgiving here, as is (for
example) syslog.conf, which was modified to be more "friendly" a while
back. Note, I'm not saying that improvements cannot be made in existing
tools, just that discarding them completely doesn't make sense.
> Worse, Makefile writers commonly embed code from
> other languages (e.g., awk, sed, sh), creating something that only
> a script wizard can parse.
Once again, this is just a matter of familiarity. I am far from a makefile
expert, but the common patterns in a makefile are now second nature to me.
I'm sure that the common patterns of XML are familiar to you as well, but
please don't mistake "familiar to you" with "easy." Keep in mind, there is
nothing "intuitive" in any part of the CS world. It's all a matter of what
you're familiar with, and how new things relate to prior learning.
> 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.
XML makes CGI tools easier, that's about it. Everything else is just a
matter of writing good parsing tools, and being consistent with the format
of the files themselves.
> 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 :-).
Once again, this is a matter of picking the right tool for the job. I
could parse that same printcap file in about 20 lines of perl, and I
wouldn't even consider awk for the job.
> 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...
I'm not saying that XML is universally a bad thing. I'm just saying that I
don't think it's right for almost anything that it's being proposed for in
FreeBSD.
> 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...
Thankfully, this isn't Jordan's decision.
--
I need someone really bad. Are you really bad?
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?3B14CE8C.AC8137A0>