[Feature] Manage doc and test instructions in BLFS

[pierre-labastie]

Is your feature request related to a problem? Please describe. A lot of editing has to be done on BLFS scriptlets because there are instructions for installing doc or for testing, which can only be run when optional dependencies are present. OTOH, removing them completely is not desirable.

Describe the solution you'd like The solution is twofold: have BLFS signal those kinds of instructions (add remap="doc" or remap="test" attibutes), and treat those attributes in jhalfs (this project is only concerned with the second part).

• if building a package without timing/sizing: comment out the instruction in both doc and test case
• if building with timing/sizing:
  • for doc: don't modify the instruction
  • for test: change make to make -k and add >> $TESTLOG 2>&1 || true (may be tricky for multiline)

Describe alternatives you've considered if BLFS do not want the remap attributes, then make all the doc/test instructions in <screen><useriput> tags role="nodump". Actually, it might be a good idea to output any <screen><userinput> instruction, and comment out the instruction if it has attribute role="nodump".

Additional context The logic for test instructions is already implemented in case they are in a <command> tag.

[pierre-labastie]

Actually, we are arriving at a point where several changes to the instruction string have to be done, depending on various conditions:

• Always remove && at the end of lines, except if the line contains test or[, then remove trailing spaces
• If role="nodump": comment out each line
• If role="doc" and the current package is not in list-stat (we should use a global Boolean variable instead of a test each time), comment out each line
• If role="test": change make to make -k, and:
  • If the current package is not in list-stat: comment out each line
  • else: append >> $TESTLOG 2>&1 || true to each line, except for lines ending with \
• In install mode, replace make with make -j1
• In install mode, if $wrap-install="y": replace ' with '\''
• If role="root" and $sudo="y": escape \, `, and $
• In DESTDIR mode: change / ("space-slash") to $PKG_DEST/, and >/ to >$PKG_DEST/, make to make DESTDIR=$PKG_DEST, and ninja to DESTDIR=$PKG_DEST ninja

Right now, we use templates which call another template, which calls another template, ..., using mode attributes for treating the various cases. This may become very tricky now that we have many more conditions.

What we could do is the following: start with the string, and test conditions for applying the first template (say "template-1"). If true, pass the string to template-1 and have the output go to variable-1, else set variable-1 equal to the string unchanged. Then test conditions for applying template-2: If true, pass variable-1 to template-2 and have the output go to variable-2, else pass variable-1 into variable-2 unchanged, and so on. Note that the problem is that variables in XSLT are immutable. Otherwise, we could keep the same variable. OTOH, apart from the immutability problem, I think this could be a good algorithm for our future backends in Python, too.

[pierre-labastie]

What we could do is the following: start with the string, and test conditions for applying the first template (say "template-1"). If true, pass the string to template-1 and have the output go to variable-1, else set variable-1 equal to the string unchanged. Then test conditions for applying template-2: If true, pass variable-1 to template-2 and have the output go to variable-2, else pass variable-1 into variable-2 unchanged, and so on. Note that the problem is that variables in XSLT are immutable. Otherwise, we could keep the same variable. OTOH, apart from the immutability problem, I think this could be a good algorithm for our future backends in Python, too.

Using variables may not be the best. <param>/<with-param> could be better suited. Actually, we could even try to keep a node set so:

<xsl:call-template name="cook-instructions">
  <xsl:with-param name="nodeset"
     select=".//screen|.//command[contains(string(),'test') or contains(string(),'check')]"/>
  <xsl:with-param name="root-seen" select="boolean(0)"/>
  ...other params...
</xsl:acall-template>
<!-- and the template -->
<xsl:template name="cook-instructions">
  <xsl:param name="nodeset"/>
  <xsl:param name="root-seen"/>
  ...other params...
  <xsl:for-each select="$nodeset[1]"><!-- have to check the syntax -->
    <!-- treat that node -->
    <xsl:call-template name="cook-instructions">
      <xsl:with-param name="nodeset" select="$nodeset[position()>1]"/>
      <xsl:with-param name="root-seen" select="...adjust depending on conditions..."/>
      ...other params...
    </xsl:call-template>
  </xsl:for-each>
</xsl:template>

Of course, I'm open to other suggestions. I've tried various other options, and all seem to lead to complicated, fragile constructs.

[pierre-labastie]

Ooops, forgot to write: if $nodeset is empty, we should return from cook-instructions!

[pierre-labastie]

Much of this has been implemented on the jhalfs repo at linuxfromscratch.org. Closing here, since the master branch is now using (partly) Python.