Date: Wed, 30 May 2001 11:05:35 -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: <3B15366F.4C30F735@DougBarton.net> References: <20010528105709.A9284@c187104187.telekabel.chello.nl> <p05001905b739a3d1c212@[192.168.168.205]> <3B14CE8C.AC8137A0@DougBarton.net> <p05001912b73ac3ed7a23@[192.168.168.205]>
next in thread | previous in thread | raw e-mail | index | archive | help
Rich Morin wrote: > > 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, Then you're going to have a hard time convincing anyone to adopt your framework. If you can't point to evidence that shows exactly how your system is better, why should we bother? > 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. That's essentially what we have now with the bmake ports tree. The various .mk files have the information needed to make things work on the various combinations of platforms and os'es. > 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. Once again, all you've done here is describe reality. If your goal is to build a bsd-licensed system that all RPM users will adopt immediately, you're doomed to failure from the start. If the system is not bsd licensed, we won't use it. There will always be various port build and installation systems for various os'es. The philosophical differences are too great for there not to be. > 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. How much do you know about bmake and *.mk files? You've basically described the way the current ports system works. > 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. Each individual port contains the specific information about how building that port differs from the theoretical norm, and information on where to put the files created by that port. I'm not sure where you're getting the "information about FreeBSD's structure" there, can you give an example? > >XML makes CGI tools easier, that's about it. > > XML is being used (rightly or wrongly :-) for a variety of tasks. You are quoting me out of context again. The context of my comment here was in response to a specific set of things you said XML would make easier for the ports system. > CGI > scripting is only the tip of the iceberg. XML is well suited to tasks > that require serialization of hierarchical data structures. I'm not debating that point. > >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. But that doesn't prevent me from using those tools to test configurations too. Many unix commands have an option like the -n option to make that let you run the command to completion through the parser without taking any actions. > Part and parcel of this is the > fact that the "format of the files themselves" is NOT "consistent". Actually I agree that in many cases the file formats are not consistent, but that doesn't make it part of the above described situation. No matter how tight the DTD I can write inconsistent XML with it too. We've demonstrated several times over the past 8 months or so that we have a remarkable amount of consistency across the 5,000+ ports in our current system. This requires rigorous enforcement, along with tools like portlint that make consistency checking easier, but it's very doable. > >> 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". And there are many others, I merely illustrated my point by picking the tool I'd have used to handle your example. > 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. Yes, as you expand the universe out to every badly written <foo> it becomes harder to enforce consistency using existing tools. But we are speaking here specifically of the ports system which _does_ already have mechanisms for enforcing consistency, parsing their content, etc. > In contrast, XML input routines (I use XML::Simple) can handle any > well-formed XML string. And here you are comparing apples and oranges. You're comparing good XML to bad Makefiles, etc. As I've stated before, bad XML is just as hard to work with as bad anything else. > 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... Quite. I've now restated my major points at least once each on this thread, so barring any more major mispresentations of my positions, I'll let others comment if so desired. Doug 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?3B15366F.4C30F735>