Re: Future automation possibilities

As someone who has attempted to implement this same concept in Python of
reading the book XML and running commands as needed, It was incredibly
difficult trying to triangulate the XML tree of the book to identify some
sort of consistent pattern to use without also creating a lookup table for
certain chapters which breaks forward compatibility when the book structure
changes.  I understand that the book's XML is ideal for the context of
publishing a document, so hesitation to change this is warranted.  But I
wonder if a compromise would be for Jeremy or a delegate to provide a set
of tags to the LFS dev team that would help to identify which type of text
box is being used (run in chroot, run as lfs user, etc.) to provide that
metadata for automation.

Thanks!
Craig Jackson
[email protected]
253-459-5384 cell


On Fri, Sep 30, 2022 at 3:51 PM Jeremy Huntwork <
[email protected]> wrote:

> Hello,
>
> Just following up from a conversation Pierre and I were having on IRC
> about the potential for a revitalized automation tool. We talked about
> updating some of the jhalfs code-base to a more full-featured language like
> Python. I also mentioned investigating Go. I like that option because of
> the ease of producing tests with Go and it also lets us potentially create
> a static runtime binary with no external dependencies. (Zig would too, and
> I'm also investigating that as a possibility.)
>
> As I was experimenting, I wanted to see what would be involved in
> rendering the book's stylesheets as they are, without requiring xsltproc
> itself. Here's a really rough piece of code that is based on what xsltproc
> does (as discovered by looking through its source):
> https://gitlab.com/-/snippets/2420214
>
> The settings of the params there are of course really ugly and would need
> to change to be fed/set dynamically, but at least this code produces
> identical results to xsltproc.
>
> The question I have is, do we want to be setting/applying configuration
> options via a stylesheet still? I'm not raising the question of changing
> the book structure, just the lfs.xsl that ships with jhalfs. Is that the
> tool that we prefer to choose between various build options?
>
> I ask because as I read it, it seems very confusing. I'm wondering if it
> would be better to just parse xml attributes directly and make decisions
> with the code afterwards?
>
> I'm willing to work with the existing xsl, but am curious to hear opinions.
>
> Thanks,
>
> JH
> --
> http://lists.linuxfromscratch.org/sympa/info/alfs-discuss
> Unsubscribe: See the above information page

-- 
http://lists.linuxfromscratch.org/sympa/info/alfs-discuss
Unsubscribe: See the above information page