Boost.Sort - new library documentation

Is there anything more that should be done to ensure that Boost.Sort new library documentation is added to the build system. It uses Quickbook, Doxygen and Autoindex. So does anything need adding to modular-boost\doc\Jamfile.v2 ? Perhaps, if I have understood this comment correctly: # Note that when refering to libraries that use auto-index we must process all the way to # docbook before including here. We must also ensure that auto-index uses it's own index # generation, otherwise we get one big index that's repeated in each library. Xslt's index # generation is also so slow that it's impractical for a build this large (takes ~ 9 hrs # to build with just 3 indexed libraries). Hence we refer to these libraries as for example: # # ../libs/interprocess/doc//standalone/<format>docbook then this needs adding ## Build the various generated docs (Doxygen and QuickBook)... <dependency>../libs/sort/doc//standalone/<format>docbook ## Add path references to the QuickBook generated docs... <implicit-dependency>../libs/sort/doc//standalone/<format>docbook but I am not clear if this is right, so I am not providing a pull request. I'm also unclear who should/will do this. Thanks Paul PS I suspect that I will also need this for Boost.Integer update soon. --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

I've added a pull request: https://github.com/boostorg/boost/pull/49,
because no one has said this is wrong.
On Tue Jan 20 2015 at 5:09:44 AM Paul A. Bristow
Is there anything more that should be done to ensure that Boost.Sort new library documentation is added to the build system.
It uses Quickbook, Doxygen and Autoindex.
So does anything need adding to
modular-boost\doc\Jamfile.v2 ?
Perhaps, if I have understood this comment correctly:
# Note that when refering to libraries that use auto-index we must process all the way to # docbook before including here. We must also ensure that auto-index uses it's own index # generation, otherwise we get one big index that's repeated in each library. Xslt's index # generation is also so slow that it's impractical for a build this large (takes ~ 9 hrs # to build with just 3 indexed libraries). Hence we refer to these libraries as for example: # # ../libs/interprocess/doc//standalone/<format>docbook
then this needs adding
## Build the various generated docs (Doxygen and QuickBook)...
<dependency>../libs/sort/doc//standalone/<format>docbook
## Add path references to the QuickBook generated docs...
<implicit-dependency>../libs/sort/doc//standalone/<format>docbook
but I am not clear if this is right, so I am not providing a pull request.
I'm also unclear who should/will do this.
Thanks
Paul
PS I suspect that I will also need this for Boost.Integer update soon.
--- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

On 22 January 2015 at 02:57, Steven Ross
I've added a pull request: https://github.com/boostorg/boost/pull/49, because no one has said this is wrong.
That will just generate the docbook files. What you want to do depends on whether you want to build standalone documentation in the module, or be part of the combined documentation. I'm guessing the former, so I just need to add your library to my build script.

On Thu Jan 22 2015 at 3:21:51 PM Daniel James
On 22 January 2015 at 02:57, Steven Ross
wrote: I've added a pull request: https://github.com/boostorg/boost/pull/49, because no one has said this is wrong.
That will just generate the docbook files. What you want to do depends on whether you want to build standalone documentation in the module, or be part of the combined documentation. I'm guessing the former, so I just need to add your library to my build script.
I was planning on standalone documentation (under the assumption that was more modular), so adding it to your build script sounds good, but have no objection to it being in the combined documentation if that's better for some reason.
participants (3)
-
Daniel James
-
Paul A. Bristow
-
Steven Ross