Date: Wed, 30 May 2001 09:36:20 -0700 From: Rich Morin <rdm@cfcl.com> To: ports@FreeBSD.ORG Subject: Re: XML-based ports system ? Message-ID: <p05001912b73ac3ed7a23@[192.168.168.205]> In-Reply-To: <3B14CE8C.AC8137A0@DougBarton.net> References: <20010528105709.A9284@c187104187.telekabel.chello.nl> <p05001905b739a3d1c212@[192.168.168.205]> <3B14CE8C.AC8137A0@DougBarton.net>
next in thread | previous in thread | raw e-mail | index | archive | help
At 3:42 AM -0700 5/30/01, Doug Barton wrote: >You still haven't demonstrated quantitatively _how_ your proposed >system would be better. ... These aren't quantitative issues, in particular, but there are some quantitative benefits that might accrue. Picture a "porting matrix" which is defined by a variety of programs (P), hardware architectures (H), and operating systems (O). In the worst-case scenario, P*H*O ports need to be written to make all of the possible combinations work. And, in fact, that is about how things looked only a few years back. Fortunately, the current situation has improved markedly. Configure and related tools (along with more abstract use of ifdef) have largely resolved the C-level porting issues for hardware and OS variants. We still need to solve the issues that relate to build and installation, however, and the current raft of "solutions" (e.g., Ports Collections, RPMs) is far from being a single, generic answer to the problem. Ideally (IMHO), there would be a file that describes each program's build and installation requirements. Other files would describe the preferences of the target OS, user, host, network, etc. It would then be the job of the "build system" to reconcile all of this information for a given installation scenario. The quantitative benefit of this scheme is that each type of porting information only needs to be written down once. Contrast this with the current situation, in which each "port description" contains (albeit implicitly) a variety of information about FreeBSD's structure. >XML makes CGI tools easier, that's about it. XML is being used (rightly or wrongly :-) for a variety of tasks. CGI scripting is only the tip of the iceberg. XML is well suited to tasks that require serialization of hierarchical data structures. It can be made to work with more general graphs, but not always well. >Everything else is just a matter of writing good parsing tools, and >being consistent with the format of the files themselves. Ah, but Unix doesn't have "good parsing tools" for most of the data formats it uses. Rather, the code to parse each control file is part of the routine(s) that use the file. Part and parcel of this is the fact that the "format of the files themselves" is NOT "consistent". >> 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. Perl can be made to parse almost anything, with enough effort, but it is only one tool, not "lots of tools for manipulating text files". My point in mentioning awk is that it is the only traditional Unix tool that is even reasonably applicable to the problem of parsing control files (well, a masochist might use sed or lex :-). Awk breaks down, however when the field structure gets complex. As part of the Meta Project, I have written some Perl scripts that parse a wide range of control files. Any given control file may be fairly easy to parse (and there are some common patterns). It takes some fairly tricky coding and/or explicit handling of special cases, however, to handle the entire range. Parsing arbitrary Makefiles and/or shell scripts is an even harder problem. In contrast, XML input routines (I use XML::Simple) can handle any well-formed XML string. Once the information has been parsed, it becomes reasonable (and even easy) to ask questions about the way that the system is constructed. But that is another topic... -r -- 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?p05001912b73ac3ed7a23>