On 10/17/06, M.Canales.es <[EMAIL PROTECTED]> wrote:
El Martes, 17 de Octubre de 2006 20:00, Dan Nicholson escribió:
> Then, during the command extraction during jhalfs, you could query for
> this role and define extra <xsl:text> actions that surround this text.
> This is really no different than what the paco patch appears to be
> doing now, except it's not hardcoding things by looking for string().
Yes, in theory that is a good method, not only for PM but also for other stuff
and customizations.. But that implies that all book's sources will need be
redone thinking on atomatization.
Maybe I'm in the minority, but I think that's a useful goal. To me, it
seems like most of the editors are just following XSL convention
anyway. I.e., in BLFS we're adding role="root" because somebody said
to do it. If we were to start saying add role="install" and did the
initial mass changeover, I don't think anyone would have too big a
problem.
> Now, here's where I'm totally lost by not knowing xsl. I'd like it if
> the lfs.xsl script "included" something like pm.xsl where you could
> define custom actions that would be triggered for the "install" role.
> Basically, I think it would be preferable if the dumped commands
> contained all the extra processing instead of mangling LFS/master.sh
> to add commands to the Makefile.
>
> Is this possible?
For example, in LFS, for the unpack code we need to know what package nane is
associated with each XML page.
At bash level is easy to grep a packages list searching what package match a
script filename.
At XSL level I can't find yet an easy way to do that. Maybe that could be
implemented via key() and document() functions. The easiest way is to add the
package name to the XML file that build it, like in BLFS. But again, that
meant to change the book sources thinking on automatization.
Could you point me to some XSL documentation? Maybe some newbie level
stuff, too? This is my major stumbling block in mapping between book
and build. You guys are doing kick ass work on jhalfs, but I think
there's some lower level work that could be done to make it more
powerful without requiring lots of workarounds at the higher level.
Thanks.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
