the move to custom xml

Seth W.Klein sk at sethwklein.net
Wed Apr 9 16:39:31 PDT 2003


Jesse Tie-Ten-Quee <highos at linuxfromscratch.org> wrote:
> On Tue, Apr 08, 2003 at 05:56:01PM -0400, Seth W. Klein wrote:
> > 
> > 1: [ALFS] invents a new (XML) format for commands when we already have
> >    (ba)sh. This is not ideal because, not only does it save effort
> >    to use an existing tool where possible, but reinventing sh is
> >    unlikely to produce anything better since if there was anything
> >    better someone would have developed it in the last 30 years or so
> >    during which far brighter minds than ours have been using Unix sh.
> 
> Well..  The XML for ALFS never *suppose* to replace the shell.  The
> current incarnations do somewhat that, and I do agree it's wrong.  But
> that has more todo with *how* you decide to implement it.  If you kept the
> original goals of just writting a specification of the XML on the
> information stored, then you could do anything with that information.
> 
> If that means converting it via an implementation like nALFS does into
> basic shell commands that are run todo the job, or to convert it to
> actually bash shell scripts, wouldn't matter.  As that's not what ALFS was
> suppose to be about...

Examples are always good so let me try one. ALFS does like:

<configure base="$LFS/gcc-3.2.2">
  <option>--prefix=/usr</option>
</configure>
<make base="$LFS/gcc-3.2.2"/>
<make base="$LFS/gcc-3.2.2">
  <option>install</option>
</make>

That's not the actual ALFS syntax, it's been a while, but you get the
idea. I'm doing:

<commands>
cd $LFS/gcc-3.2.2
./configure --prefix=/usr
make
make install
</commands>

The second reuses an existing format, is more readable (IMHO), and
the XSL to convert it to sh is one template instead of three. That
might not be enough difference for some, but it is for me.

> > $ make stage1.sh
> > xsltproc --xinclude --withstringparam want stage1 build.xsl index.xml
> > $ su - -c "sh `pwd`/stage1.sh"
> 
> Uh, i'm slightly confused after reading all that.. did you convert
> everything into scripts in one shot, or are you actually putting all the
> information into XML and then using XSL to convert it to a shell script?

Extract is the word i would use, as illustrated in the example above.

> It does sound interesting and you raise alot of points I would not mind
> discussing further ;)

Let's code instead, shall we? :)

> > My one concern is the check script which hits ftp.gnu.org once for
> > each package from there. I could see them getting quite argry with me
> > if 500 lfs-dev subscribers got home between 17:00 EDT and 18:00 PDT
> > and ran the thing. It would be even worse if a few thousand freshmeat
> > or slashdot readers got wind of it.
> 
> Could use the http interface.  Less work for the FTP server then, you'd
> think.

/me slaps self on head for not thinking to try and see if they had
httpd running. I'll switch my data over anyway because i think http
should be faster for just pulling indexes, but i might call that
good enough.

Since there's been no expressed interest except Jesse's and right now
it's just a glorified wget script (very cool script, but still...)
i won't bother with the README writing necessary for a release here.
If you want a tarball, catch me on IRC.

cheers,
Seth W. Klein
-- 
sk at sethwklein.net                         http://www.sethwklein.net/
Maintainer, LFS FAQ             http://www.linuxfromscratch.org/faq/
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list