Le 26/02/2014 16:54, Gregory H. Nietsky a écrit : > On 26/02/2014 11:29, Pierre Labastie wrote: >> Maybe, when there is more time, we could start a related discussion >> about having optional instructions in the book not distinct in any way >> from mandatory ones. As you may remember, I use some kind of automation >> for testing the book. If optional instruction removing cannot be >> automated, it takes a lot more time to do it manually. OTOH, if I make >> scripts for testing the book, I may as well end up testing my scripts >> rather than what is written in the book. That's the main reason for >> automation: extracting the current instructions as written in the book, >> and testing them. If I have to modify manually the generated scripts, I >> test my work (and it is much more time consuming). >> >> Of course, full automation cannot be achieved, and is not desirable, so >> setting general rules is not easy. > There is something that is often overlooked that there are individuals > who use the "book" as a reference to get the low down on a individual > package. > if these are <place common distro here> users or simply experimenting > with the package > its a awesome resource. not all readers of the book are builders. > > its a lot easier reading the xLFS page than wading through configure > --help/README/.... > > Greg I agree that in an ideal world, all the options, and all the ways to build a package could be in the book. But reality is such that it is impossible. Now, where is the limit. I think there is a common agreement that only the "recommended" instructions are supposed to have been tested by the editor. And there is a lot of testing involved when there is an average of 2 or 3 new versions per day (notwithstanding the extensive testing before a release). So it seems impossible to present more than a few options on a page. Furthermore those may not have been tested. And I think the book is good as a reference if those options show an uncommon way to do things, or a peculiarity specific to the package. Building doxygen docs and/ot alternate formats of the docs is pretty standard, and documented in the autotools. There is no much added value in putting explicitly instructions for that, since a user can easily figure them out. Actually building a 3Gb package (TeXLive) for just testing building docs for a "small" utility seems just a waste of time. I would not say the same about sendmail (see the other current thread), which has a rather uncommon build and configuration system (I would not say that it's easy, although I think everything is easy once you know it...).
Pierre -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
