Re: [gentoo-dev] portage database management

[Alain Penders]

That's indeed the main problem with XML.  If you want to see the practicality 
of this, take a look at Ant (http://ant.apache.org/).  Ant is a Java based 
build system, kinda like Makefiles but WAY more powerful.  It's slowly 
becoming the defacto standard for building Java projects, and especially for 
large Java projects it's invaluable.

It defines a project in XML, and comes with a lot of modules (comparable to 
eclasses and the default ebuild commands) which can be used inside that XML.

Implementing an ebuild in Ant would be very simple, and probably with one or 
two additional modules one could implement all of portage in ant.  Doing the 
latter would be way slower than portage is today though, and doing the first 
requires adding Java... not very useful right now either.

Looking at the cheer size of Ant -- all the stuff they had to put in before it 
became a really useful system, I'd vote against trying to do this for portage.  
Having an XML definition for each package, yes... replacing the actual build 
code by XML - no.

My $0.02...

Alain


On Thu, Feb 06, 2003 at 03:41:29AM -0600, Jared H. Hudson wrote:
> I like XML as much as the next guy, but one thing you should remember is
> that ebuilds are not some arbitrary pkg format -- they're bash scripts.
> They may not look it, since they don't have #!/bin/bash at the top, but
> they are bash scripts that are sourced with other bash scripts. So, for
> example, most ebuilds have bash functins like src_unpack, src_install,
> ect, but others have their own functions that are defined and called by
> these src_* functions. Converting this to XML would mean that portage
> would have to convert everything to bash, plus there'd have to be enough
> flexibility in the XML stylesheet we'd to include the possibility of
> unknown-ebuild-specific global variables, functions, ect.
>
> Just food for thought.
>
> -Jared H.

--
gentoo-dev@g.o mailing list