On January 2, 2019 6:55:52 AM CST, Kevin Buckley via lfs-dev wrote: > >The one other thing I noticed is that there must be some automatic >re-formatting of the XML going on (?) after changes are made, in that >a couple of the patch chunks only failed to apply to the vanilla 8.3 >XML >because the context lines didn't match after a line had been wrapped >slightly >differently.
Nothing automated in that. Likely my doing, but 81 ! <= 80. :-) > >In order to generate some dumps of the <screen><userinput> sections >for my own purposes (see previous postings) I ran the following against >XML sources that had been patched with Thomas's patch and saw > >$ make ARCH=multilib all-but-pdf >Creating and cleaning ../../tmp >Processing bootscripts... >Adjusting for revision sysv... >chapter03/patches.xml:130: parser error : Entity >'systemd-glibc-patch-size' not defined ><term>systemd glibc patch - ><token>&systemd-glibc-patch-size;</token>:</te > ^ >chapter03/patches.xml:132: parser error : Entity 'systemd-glibc-patch' >not defined ><para>Download: <ulink >url="&patches-root;&systemd-glibc-patch;"/></para > ^ >chapter03/patches.xml:133: parser error : Entity >'systemd-glibc-patch-md5' not defined > <para>MD5 sum: <literal>&systemd-glibc-patch-md5;</literal></para> > ^ >Validating the book... >Validation complete. >Generating profiled XML for XHTML... >Generating chunked XHTML files at >... > >but the patched book was generated as expected, however I was wondering >why the "systemd" patches were being referred to given the > >"Adjusting for revision sysv..." > >line. > >Is that just an atrefact of doing a "fuller" make that just a >rendering of the HTML >or something actually missing in the "development" XML sources ? > The wget scripts grab files for both books. I suppose doing the first pass might break things slightly. I'll have to take a peek at it. > >Looks like I will have to go back to a full redeployment though, as I >see that >the Chapter 5 utilities now have some 32-bit stuff in, whereas my >modified 8.3 >Chapter 5 didn't. > Yeah, doing the build inline is certainly better from a maintenance POV. It adds a couple of extra builds, but the reduced maintenance burden (which should ultimately result in an increase in accuracy being the instructions are on the same page), far outweighs the minimal cumulative SBU increase. Thomas's patch likely doesn't require much if any manual intervention. >I also note that Thomas's patch adds in ISL to the GCC Chapter 5 build: >is >that needed for the Chapter 6 32-bit builds (which also have ISL) or >just a >"nice to have" addition ? > Also my doing. It was just an artifact of an earlier build, but decided to leave it in there, that way, even though rarely used, all of the GCC deps are covered in the early phase. You should probably be able to omit if inclined, though not tested. The same is true for chapter 6. ISL is not required, nor are the complex loop optimizations that use it all that common in the wild. That said, it's a very small dep who's build time and disk space are negligible, and it might be used elsewhere if building software that is heavy in physics or geometry. --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
