Future automation possibilities

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