Re: [boost] [release] 1.69.0 deadline for new libraries approaching
Robert Ramey wrote:
On 10/22/18 10:19 AM, Peter Dimov via Boost wrote:
Marshall Clow wrote:
* 24-Oct: Boost 1.69.0 closed for new libraries and breaking changes
OK... do we want CMake config files installed by 1.69 or not, then?
I'd like to know this as well. If so, I presume that we can consider the Boost/CMake issues resolved and we can just move on from this?
I doubt it. The CMake issue is much bigger than this.
To expand on that: The Boost/CMake issues concern four scenarios: 1. CMake users who want to use a pre-built Boost from CMake, after installing it either with `b2 install`, as usual, or via some other mechanism; 2. CMake users who want to use Boost (or an individual Boost library) from CMake without building it with b2 and installing it, but as a subproject, built by CMake; 3. Building and installing Boost with CMake, replacing the current Boost.Build building/installing infrastructure; 4. Testing Boost with CMake, replacing the current Boost.Build testing infrastructure. Installing CMake config files as part of `b2 install` falls into scenario number 1. Boost is still built with Boost.Build as always, it's just that in addition to libboost_foo.a, the user also gets libboost_foo.cmake, which allows him to do `find_package(boost_foo)` from his CMakeLists.txt file. Nothing more than that. This doesn't affect, doesn't target, and doesn't address, scenarios 2-4 at all.
On 10/22/2018 7:55 PM, Peter Dimov via Boost wrote:
Robert Ramey wrote:
On 10/22/18 10:19 AM, Peter Dimov via Boost wrote:
Marshall Clow wrote:
* 24-Oct: Boost 1.69.0 closed for new libraries and breaking changes
OK... do we want CMake config files installed by 1.69 or not, then?
I'd like to know this as well. If so, I presume that we can consider > the Boost/CMake issues resolved and we can just move on from this?
I doubt it. The CMake issue is much bigger than this.
To expand on that:
The Boost/CMake issues concern four scenarios:
1. CMake users who want to use a pre-built Boost from CMake, after installing it either with `b2 install`, as usual, or via some other mechanism;
2. CMake users who want to use Boost (or an individual Boost library) from CMake without building it with b2 and installing it, but as a subproject, built by CMake;
3. Building and installing Boost with CMake, replacing the current Boost.Build building/installing infrastructure;
4. Testing Boost with CMake, replacing the current Boost.Build testing infrastructure.
5. Building a library's documentation with CMake. Quite a number of libraries currently use the Quickbook -> Boostbook -> html/pdf cycle with built-in support by Boost Build for this with a jamfile.
Installing CMake config files as part of `b2 install` falls into scenario number 1. Boost is still built with Boost.Build as always, it's just that in addition to libboost_foo.a, the user also gets libboost_foo.cmake, which allows him to do `find_package(boost_foo)` from his CMakeLists.txt file. Nothing more than that. This doesn't affect, doesn't target, and doesn't address, scenarios 2-4 at all.
On 10/22/18 8:02 PM, Edward Diener via Boost wrote:
5. Building a library's documentation with CMake. Quite a number of libraries currently use the Quickbook -> Boostbook -> html/pdf cycle with built-in support by Boost Build for this with a jamfile.
Maybe - but personally I just build my docs pdf and html with a simple shell script - it's about 5 lines long - easy as pie. Robert Ramey
On 10/23/2018 12:33 AM, Robert Ramey via Boost wrote:
On 10/22/18 8:02 PM, Edward Diener via Boost wrote:
5. Building a library's documentation with CMake. Quite a number of libraries currently use the Quickbook -> Boostbook -> html/pdf cycle with built-in support by Boost Build for this with a jamfile.
Maybe - but personally I just build my docs pdf and html with a simple shell script - it's about 5 lines long - easy as pie.
1) Shell scripts are different for Windows, Linux, and Mac OSs. 2) Please provide your "simple" shell script for any OS, much less all of them, that encapsulates the quickbook -> boostbook -> html/pdf process in jam files. Try to understand that even if you do not use the quickbook -> boostbook -> html/pdf build process a great number of libraries do use it, for good reason, and those libraries are not going to re-invent the wheel just because you have an alternate method for creating documentation.
Robert Ramey
On 10/22/18 9:46 PM, Edward Diener via Boost wrote:
On 10/23/2018 12:33 AM, Robert Ramey via Boost wrote:
On 10/22/18 8:02 PM, Edward Diener via Boost wrote:
5. Building a library's documentation with CMake. Quite a number of libraries currently use the Quickbook -> Boostbook -> html/pdf cycle with built-in support by Boost Build for this with a jamfile.
Maybe - but personally I just build my docs pdf and html with a simple shell script - it's about 5 lines long - easy as pie.
1) Shell scripts are different for Windows, Linux, and Mac OSs. 2) Please provide your "simple" shell script for any OS, much less all of them, that encapsulates the quickbook -> boostbook -> html/pdf process in jam files.
Try to understand that even if you do not use the quickbook -> boostbook -> html/pdf build process a great number of libraries do use it, for good reason, and those libraries are not going to re-invent the wheel just because you have an alternate method for creating documentation.
Here is the the script I use to build html documentation for the safe numerics library: if test x = x$BOOST_ROOT then echo BOOST_ROOT not set exit 1 fi xsltproc --nonet --xinclude bb2db.xsl safe_numerics.xml | xsltproc --nonet db2html.xsl - cp pre-boost.jpg ../html cp pre-boost.jpg ../html/eliminate_runtime_penalty cp pre-boost.jpg ../html/promotion_policies cp pre-boost.jpg ../html/tutorial cp StepperMotor.gif ../html/ cp stepper_profile.png ../html/ cp $BOOST_ROOT/doc/src/boostbook.css ../html cp -R $BOOST_ROOT/doc/html/images ../html If you want to use it feel free. Note that it transforms boostbook => html. How your boostbook file(s) are created is not addressed here. if you want to include quickbook in the pipeline or use something like it windows, You'll just have to alter the script to taste. Sorry I can't do this for you. Note that it's actual function is to cut B2 out of the mix. This makes things much, much simpler. BTW there are other versions to produce pdf and ebook from the boostbook files.
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
AMDG On 10/23/2018 08:54 AM, Robert Ramey via Boost wrote:
On 10/22/18 9:46 PM, Edward Diener via Boost wrote:
On 10/23/2018 12:33 AM, Robert Ramey via Boost wrote:
On 10/22/18 8:02 PM, Edward Diener via Boost wrote:
5. Building a library's documentation with CMake. Quite a number of libraries currently use the Quickbook -> Boostbook -> html/pdf cycle with built-in support by Boost Build for this with a jamfile.
Maybe - but personally I just build my docs pdf and html with a simple shell script - it's about 5 lines long - easy as pie.
1) Shell scripts are different for Windows, Linux, and Mac OSs. 2) Please provide your "simple" shell script for any OS, much less all of them, that encapsulates the quickbook -> boostbook -> html/pdf process in jam files.
Try to understand that even if you do not use the quickbook -> boostbook -> html/pdf build process a great number of libraries do use it, for good reason, and those libraries are not going to re-invent the wheel just because you have an alternate method for creating documentation.
Here is the the script I use to build html documentation for the safe numerics library:
if test x = x$BOOST_ROOT then echo BOOST_ROOT not set exit 1 fi xsltproc --nonet --xinclude bb2db.xsl safe_numerics.xml | xsltproc --nonet db2html.xsl -
You need a catalog file for --nonet to work. This script is not self-contained, because it assumes that the catalogs for boostbook and docbook are present in the environment.
cp pre-boost.jpg ../html cp pre-boost.jpg ../html/eliminate_runtime_penalty cp pre-boost.jpg ../html/promotion_policies cp pre-boost.jpg ../html/tutorial cp StepperMotor.gif ../html/ cp stepper_profile.png ../html/ cp $BOOST_ROOT/doc/src/boostbook.css ../html cp -R $BOOST_ROOT/doc/html/images ../html
If you want to use it feel free.
Note that it transforms boostbook => html. How your boostbook file(s) are created is not addressed here. if you want to include quickbook in the pipeline or use something like it windows, You'll just have to alter the script to taste. Sorry I can't do this for you.
And that's the real issue. Scripts like this are work great as long as you're only running them in a specific environment. If you try to make them portable, they'll quickly become at least as complex as the b2 implementation.
Note that it's actual function is to cut B2 out of the mix. This makes things much, much simpler.
BTW there are other versions to produce pdf and ebook from the boostbook files.
In Christ, Steven Watanabe
On 10/23/18 8:16 AM, Steven Watanabe via Boost wrote:
You need a catalog file for --nonet to work. This script is not self-contained, because it assumes that the catalogs for boostbook and docbook are present in the environment.
Right - I added these when I discovered that the damn thing was going out on the net every time I built something.
And that's the real issue. Scripts like this are work great as long as you're only running them in a specific environment. If you try to make them portable, they'll quickly become at least as complex as the b2 implementation.
Right - that's why I didn't try to make it really portable. I made it simple enough to work and simple enough to adjust to taste. B2 places a impenetrable layer between me building the documentation. My script is 100 times easier to work with than the b2 implementation.
Note that it's actual function is to cut B2 out of the mix. This makes things much, much simpler.
BTW there are other versions to produce pdf and ebook from the boostbook files.
Robert Ramey
In Christ, Steven Watanabe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 10/23/18 9:17 AM, Peter Dimov via Boost wrote:
Robert Ramey wrote:
Right - that's why I didn't try to make it really portable.
That's fine but the Boost documentation build doesn't run on your machine, so it won't be able to use your script then.
LOL - the b2 based one doesn't run on my machine either. It's easier and faster to craft the script than to get b2 to do it. And I place the html and pdf versions into the repo so users don't have to build it. Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
And I place the html and pdf versions into the repo so users don't have to build it.
Placing the .html/pdf files into the repo is one - unquestionably modular - way to do it, but it does have its downsides.
On 10/23/18 11:17 AM, Peter Dimov via Boost wrote:
Robert Ramey wrote:
And I place the html and pdf versions into the repo so users don't have to build it.
Placing the .html/pdf files into the repo is one - unquestionably modular - way to do it, but it does have its downsides.
Both true. downside - "wastes" a lot of space - redundant - docs could get out sync with the code. upside - current documentation is always available to the user. In the two libraries of mine - documentation is an important part and I don't think the either would be usable without them. - only needs to be built on one machine no hassle for users - document build doesn't have to be "portable" - potential users can easily browse the documentation before they clone/download the package. This works well with github. I think this is very valuable - especialy for safe_numerics which most people don't actually see the need for. Call it a sales tool. For me, this is was a pretty easy decision. Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
Placing the .html/pdf files into the repo is one - unquestionably modular - way to do it, but it does have its downsides.
Both true.
downside - "wastes" a lot of space - redundant - docs could get out sync with the code.
- it complicates the process of creating and incorporating a pull request that includes documentation fixes. The submitter sometimes doesn't know or realize that the .html needs to be regenerated too, or knows it but can't get the script to work; or he changes the .html instead of the source. The usual process seems to settle into submitters just submitting patches against the source (without having means to verify if the docs still build after their changes) and then the author occasionally regenerating the docs - if he doesn't forget, which he does. But yes, it's a tradeoff that's worth it if you want users to have easy access to your documentation after cloning the repo. For Boost libraries, I myself just point people to boost.org/libs/mylib.
On 10/23/2018 2:36 PM, Robert Ramey via Boost wrote:
On 10/23/18 11:17 AM, Peter Dimov via Boost wrote:
Robert Ramey wrote:
And I place the html and pdf versions into the repo so users don't have to build it.
Placing the .html/pdf files into the repo is one - unquestionably modular - way to do it, but it does have its downsides.
Both true.
downside - "wastes" a lot of space - redundant - docs could get out sync with the code.
upside
- current documentation is always available to the user. In the two libraries of mine - documentation is an important part and I don't think the either would be usable without them. - only needs to be built on one machine no hassle for users - document build doesn't have to be "portable" - potential users can easily browse the documentation before they clone/download the package. This works well with github. I think this is very valuable - especialy for safe_numerics which most people don't actually see the need for. Call it a sales tool.
I am sure you know that github already has support for viewing the documentation via the github io mechanism, so your last '-' item is not really applicable to your argument. My argument is simply that lots and lots of libraries use Boost Build to generate the docs, very often through the quickbook -> docbook -> pdf/html mechanism and unless we are going to continue to do it that way when Boost uses CMake we will eventually need a way to duplicate the Boost Build mechanism for creating the docs in CMake. Nonetheless I continue to believe that the move to CMake by Boost should be achieved in small steps, so that we can assure success in one step for all libraries before we even think about attempting the next. I still have the same fear that trying to accomplish everything at one time will mean that nothing really will ever get done. I only added item 5) to Peter's list because that is something we will eventually have to decide about. I understand your own way of generating docs but I think this is irrelevant to the general discussion vis-a-vis Boost Build and CMake. I know you really do not believe that the solution is for everyone to generate the docs the way you do.
For me, this is was a pretty easy decision.
Robert Ramey
On 23.10.18 21:29, Edward Diener via Boost wrote:
On 10/23/2018 2:36 PM, Robert Ramey via Boost wrote:
On 10/23/18 11:17 AM, Peter Dimov via Boost wrote:
Robert Ramey wrote:
And I place the html and pdf versions into the repo so users don't have to build it.
Placing the .html/pdf files into the repo is one - unquestionably modular - way to do it, but it does have its downsides.
Both true.
downside - "wastes" a lot of space - redundant - docs could get out sync with the code.
upside
- current documentation is always available to the user. In the two libraries of mine - documentation is an important part and I don't think the either would be usable without them. - only needs to be built on one machine no hassle for users - document build doesn't have to be "portable" - potential users can easily browse the documentation before they clone/download the package. This works well with github. I think this is very valuable - especialy for safe_numerics which most people don't actually see the need for. Call it a sales tool.
I am sure you know that github already has support for viewing the documentation via the github io mechanism, so your last '-' item is not really applicable to your argument.
My argument is simply that lots and lots of libraries use Boost Build to generate the docs, very often through the quickbook -> docbook -> pdf/html mechanism and unless we are going to continue to do it that way when Boost uses CMake we will eventually need a way to duplicate the Boost Build mechanism for creating the docs in CMake.
Nonetheless I continue to believe that the move to CMake by Boost should be achieved in small steps, so that we can assure success in one step for all libraries before we even think about attempting the next. I still have the same fear that trying to accomplish everything at one time will mean that nothing really will ever get done. I only added item 5) to Peter's list because that is something we will eventually have to decide about.
Talking about small steps, feel free to copy paste this wherever you need it: https://github.com/raffienficiaud/boost-cmake/blob/master/boost-cmake/quickb... I compiled Boost.Test documentation with this, this is fully cmake and it does the catalog generation on the fly. This is a small step, usually this is where collaboration starts, since I do not have all the knowledge of quickbook/docbook nor the bandwidth ATM. *But* if somebody is kind enough to assist me on this, in particular explaining me if we would want --stringparam chunk.first.sections "1" --stringparam chunk.section.depth "4" --stringparam generate.section.toc.level "3" --stringparam html.stylesheet "boostbook.css" --stringparam toc.max.depth "3" --stringparam toc.section.depth "10" to be exposed when compiling a documentation, or how to run the doxygen part, then porting things to cmake will be definitely faster. Raffi
...and now you have changed the subject line, but are *still* replying to the same unrelated thread. *Please* start a new discussion, making sure no "In-Reply-To" header is set to relate your mail to an unrelated mail ! Stefan -- ...ich hab' noch einen Koffer in Berlin...
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Raffi Enficiaud via Boost Sent: 23 October 2018 20:53 To: boost@lists.boost.org Cc: Raffi Enficiaud Subject: [boost] boost-cmake and quickbook
On 23.10.18 21:29, Edward Diener via Boost wrote:
On 10/23/2018 2:36 PM, Robert Ramey via Boost wrote:
On 10/23/18 11:17 AM, Peter Dimov via Boost wrote:
Robert Ramey wrote:
And I place the html and pdf versions into the repo so users don't have to build it.
Placing the .html/pdf files into the repo is one - unquestionably modular - way to do it, but it does have its downsides.
Both true.
downside - "wastes" a lot of space - redundant - docs could get out sync with the code.
upside
- current documentation is always available to the user. In the two libraries of mine - documentation is an important part and I don't think the either would be usable without them. - only needs to be built on one machine no hassle for users - document build doesn't have to be "portable" - potential users can easily browse the documentation before they clone/download the package. This works well with github. I think this is very valuable - especialy for safe_numerics which most people don't actually see the need for. Call it a sales tool.
I am sure you know that github already has support for viewing the documentation via the github io mechanism, so your last '-' item is not really applicable to your argument.
My argument is simply that lots and lots of libraries use Boost Build to generate the docs, very often through the quickbook -> docbook -> pdf/html mechanism and unless we are going to continue to do it that way when Boost uses CMake we will eventually need a way to duplicate the Boost Build mechanism for creating the docs in CMake.
Nonetheless I continue to believe that the move to CMake by Boost should be achieved in small steps, so that we can assure success in one step for all libraries before we even think about attempting the next. I still have the same fear that trying to accomplish everything at one time will mean that nothing really will ever get done. I only added item 5) to Peter's list because that is something we will eventually have to decide about.
Talking about small steps, feel free to copy paste this wherever you need it:
https://github.com/raffienficiaud/boost-cmake/blob/master/boost-cmake/quickb...
I compiled Boost.Test documentation with this, this is fully cmake and it does the catalog generation on the fly.
This is a small step, usually this is where collaboration starts, since I do not have all the knowledge of quickbook/docbook nor the bandwidth ATM.
*But* if somebody is kind enough to assist me on this, in particular explaining me if we would want
--stringparam chunk.first.sections "1" --stringparam chunk.section.depth "4" --stringparam generate.section.toc.level "3" --stringparam html.stylesheet "boostbook.css" --stringparam toc.max.depth "3" --stringparam toc.section.depth "10"
to be exposed when compiling a documentation, or how to run the doxygen part, then porting things to cmake will be definitely faster.
You probably don't need all of these for Boost.Test (lots devised by John Maddock for the MASSSIVE and complex structured Boost.Math docs - so much that I ran out of the number of XSLT options permitted!). --stringparam html.stylesheet "boostbook.css" is probably needed to get the right style sheets. http://www.sagehill.net/docbookxsl/ tells you about these in general. http://www.sagehill.net/docbookxsl/ChunkingCustomization.html about chunking in general http://www.sagehill.net/docbookxsl/Chunking.html on chunking ... https://github.com/boostorg/math/blob/develop/doc/Jamfile.v2 documents the chunking and TOC settings for Math docs. My user-config.jam contains : "I:/modular-boost/dist/bin/quickbook.exe" ; to use Quickbook using xsltproc : "C:/Program Files (x86)/xsltproc_win32/xsltproc.exe" ; using boostbook : "C:/Program Files (x86)/DocBookXSL/docbook-xsl-1_77_1" # Contains eXtended Style Sheet programs. : "C:/Program Files (x86)/DocbookXML/42" # dir exists and contains docbookx.dtd 4.2 ; and get this OLD version, not the latest # Generating html from xml # using boostbook ; # boostbook standalone : array.xml : <xsl:param>boost.root=../../../.. ; # DTD (a document type definition), or schema, that provides instructions # about the structure of your particular XML document. # It's a rule book that states which tags <a_tag> are legal, and where. Doxygen # Doxygen info must come *after* boostbook info using doxygen #: "C:/Program Files/doxygen" # NOT OK - because doesn't search from path into /bin? : "C:/Program Files/Doxygen/bin/doxygen.exe" # OK ; using auto-index : "I:/modular-boost/dist/bin/auto_index.exe" ; Generating PDF is more complicated and I won't try here. Math doesn't use Doxygen (and making it do so would be a big job to make it useful to the reader). A jamfile section like doxygen autodoc : [ glob ../../../boost/svg_plot/*.*pp ] [ glob ../../../boost/quan/*.hpp ] [ glob ../../../boost/svg_plot/detail/*.hpp ] : #<doxygen:param>INPUT="filename1 directoryname2" # Separate with spaces. # But also see paths specified above. <doxygen:param>RECURSIVE=YES # Search subdirectories as well. ... should be present to build Doxygen too. Setting it up is tricky but I could advise in detail. Writing in Quickbook is pretty easy - and you can make the docs very user friendly by providing lots of links with some extra effort. Yes - it is hideously complicated, but once set up, it does the job very painlessly and the result is very nice. HTH Paul
On 2018-10-23 12:14 PM, Robert Ramey via Boost wrote: [...]
Right - that's why I didn't try to make it really portable.
Can we please simply agree that a build system for Boost needs to provide a portable way to build the docs, and then stop this off-topic discussion ? Stefan -- ...ich hab' noch einen Koffer in Berlin...
On 23.10.18 18:19, Stefan Seefeld via Boost wrote:
On 2018-10-23 12:14 PM, Robert Ramey via Boost wrote:
[...]
Right - that's why I didn't try to make it really portable.
Can we please simply agree that a build system for Boost needs to provide a portable way to build the docs, and then stop this off-topic discussion ?
Like this? https://github.com/raffienficiaud/boost-cmake/blob/master/boost/libs/test/do... and this? https://github.com/raffienficiaud/boost-cmake/blob/master/boost-cmake/quickb... Does not work well with Doxygen though. Raffi
On 10/23/18 9:19 AM, Stefan Seefeld via Boost wrote:
On 2018-10-23 12:14 PM, Robert Ramey via Boost wrote:
[...]
Right - that's why I didn't try to make it really portable.
Can we please simply agree that a build system for Boost needs to provide a portable way to build the docs,
Can we agree that it does not do that? and then stop this off-topic
discussion ?
Stefan
--
...ich hab' noch einen Koffer in Berlin...
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Robert Ramey via Boost Sent: 23 October 2018 15:54 To: boost@lists.boost.org Cc: Robert Ramey Subject: Re: [boost] [release] 1.69.0 deadline for new libraries approaching
On 10/22/18 9:46 PM, Edward Diener via Boost wrote:
On 10/23/2018 12:33 AM, Robert Ramey via Boost wrote:
On 10/22/18 8:02 PM, Edward Diener via Boost wrote:
5. Building a library's documentation with CMake. Quite a number of libraries currently use the Quickbook -> Boostbook -> html/pdf cycle with built-in support by Boost Build for this with a jamfile.
Maybe - but personally I just build my docs pdf and html with a simple shell script - it's about 5 lines long - easy as pie.
1) Shell scripts are different for Windows, Linux, and Mac OSs. 2) Please provide your "simple" shell script for any OS, much less all of them, that encapsulates the quickbook -> boostbook -> html/pdf process in jam files.
Try to understand that even if you do not use the quickbook -> boostbook -> html/pdf build process a great number of libraries do use it, for good reason, and those libraries are not going to re-invent the wheel just because you have an alternate method for creating documentation.
Here is the the script I use to build html documentation for the safe numerics library:
if test x = x$BOOST_ROOT then echo BOOST_ROOT not set exit 1 fi xsltproc --nonet --xinclude bb2db.xsl safe_numerics.xml | xsltproc --nonet db2html.xsl - cp pre-boost.jpg ../html cp pre-boost.jpg ../html/eliminate_runtime_penalty cp pre-boost.jpg ../html/promotion_policies cp pre-boost.jpg ../html/tutorial cp StepperMotor.gif ../html/ cp stepper_profile.png ../html/ cp $BOOST_ROOT/doc/src/boostbook.css ../html cp -R $BOOST_ROOT/doc/html/images ../html
If you want to use it feel free.
Note that it transforms boostbook => html. How your boostbook file(s) are created is not addressed here. if you want to include quickbook in the pipeline or use something like it windows, You'll just have to alter the script to taste. Sorry I can't do this for you.
Note that it's actual function is to cut B2 out of the mix. This makes things much, much simpler.
My script to build math docs is
b2
or >b2 pdf ;-) Paul PS But thanks for all those who did the work that went into the jamfile :-)
On 10/23/18 9:58 AM, Paul A. Bristow via Boost wrote:
My script to build math docs is
b2
or >b2 pdf
;-)
Paul
PS But thanks for all those who did the work that went into the jamfile :-)
I rest my case. Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, Oct 23, 2018 at 1:22 PM Robert Ramey via Boost < boost@lists.boost.org> wrote:
On 10/23/18 9:58 AM, Paul A. Bristow via Boost wrote:
My script to build math docs is
b2
or >b2 pdf
;-)
Paul
PS But thanks for all those who did the work that went into the jamfile
:-)
I rest my case.
Usually the problem is not b2. It's deciphering docbook and related toolchain. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net
On 23.10.18 20:27, Rene Rivera via Boost wrote:
On Tue, Oct 23, 2018 at 1:22 PM Robert Ramey via Boost < boost@lists.boost.org> wrote:
On 10/23/18 9:58 AM, Paul A. Bristow via Boost wrote:
My script to build math docs is
b2
or >b2 pdf
;-)
Paul
PS But thanks for all those who did the work that went into the jamfile
:-)
I rest my case.
Usually the problem is not b2. It's deciphering docbook and related toolchain.
I cannot agree more. Also, I consider docbook as a perfect example of extremely complex API, and this is why I am very happy with quickbook. What is your feedback on asciidoc? would you recommend it? R.
On 2018-10-23 02:58 PM, Raffi Enficiaud via Boost wrote:
I cannot agree more. Also, I consider docbook as a perfect example of extremely complex API, and this is why I am very happy with quickbook.
What is your feedback on asciidoc? would you recommend it?
Could we possibly get more off-topic ? The original discussion was about supporting *build systems*. What tools you (or anyone else for that matter) prefer is entirely irrelevant in that context, precisely because a build system needs to support them all. Stefan -- ...ich hab' noch einen Koffer in Berlin...
On 23.10.18 21:02, Stefan Seefeld via Boost wrote:
On 2018-10-23 02:58 PM, Raffi Enficiaud via Boost wrote:
I cannot agree more. Also, I consider docbook as a perfect example of extremely complex API, and this is why I am very happy with quickbook.
What is your feedback on asciidoc? would you recommend it?
Could we possibly get more off-topic ? The original discussion was about supporting *build systems*.
No. "[release] 1.69.0 deadline for new libraries approaching" is the title of this thread. I pointed you to cmake scripts that I wrote and that support building quickbook documentation. Have you tried those scripts? What tools you (or anyone else for that
matter) prefer is entirely irrelevant in that context, precisely because a build system needs to support them all.
I remember some people interested in asciidoc, and I believe Rene Rivera is/was one of them. As "a build system needs to support them all", I am asking if he would recommend it, to know if this should be supported in the future. Is there anything wrong? R.
On 2018-10-23 03:22 PM, Raffi Enficiaud via Boost wrote:
On 23.10.18 21:02, Stefan Seefeld via Boost wrote:
On 2018-10-23 02:58 PM, Raffi Enficiaud via Boost wrote:
I cannot agree more. Also, I consider docbook as a perfect example of extremely complex API, and this is why I am very happy with quickbook.
What is your feedback on asciidoc? would you recommend it?
Could we possibly get more off-topic ? The original discussion was about supporting *build systems*.
No. "[release] 1.69.0 deadline for new libraries approaching" is the title of this thread.
It is indeed. But eventually the question became whether part of that release would be certain CMake config files, which spawned the discussion on what "CMake support" actually means, which led to https://lists.boost.org/Archives/boost/2018/10/243928.php, and so on. So if you want to either discuss CMake's support for QuickBook or B2's support for AsciiDoc, you should start a new thread, rather than high-jacking this one. Stefan -- ...ich hab' noch einen Koffer in Berlin...
participants (8)
-
Edward Diener -
Paul A. Bristow -
Peter Dimov -
Raffi Enficiaud -
Rene Rivera -
Robert Ramey -
Stefan Seefeld -
Steven Watanabe