[date_time] building documentation?
I cannot build the documentation for Boot.DateTime on the develop tip - I
get an error - am I doing something wrong in the command line or is it just
broken?
jking@ubuntu:~/boost/libs/date_time/doc$ ../../../b2 boostdoc
Performing configuration checks
- default address-model : 64-bit
- default architecture : x86
../xmldoc/Jamfile.v2:54: in modules.load
*** argument error
* rule doxygen ( target : sources + : requirements * : default-build * :
usage-requirements * )
* called with: ( date_time_autodoc : :
doxygen:paramENABLE_PREPROCESSING=NO
xsl:paramboost.doxygen.reftitle=Date Time Reference
AMDG On 01/12/2018 07:47 AM, James E. King, III via Boost wrote:
I cannot build the documentation for Boot.DateTime on the develop tip - I get an error - am I doing something wrong in the command line or is it just broken?
Did you run `b2 headers` first? The glob for the headers is written for the pre-git/release tarball layout.
jking@ubuntu:~/boost/libs/date_time/doc$ ../../../b2 boostdoc Performing configuration checks
- default address-model : 64-bit - default architecture : x86 ../xmldoc/Jamfile.v2:54: in modules.load *** argument error * rule doxygen ( target : sources + : requirements * : default-build * : usage-requirements * ) <snip> * missing argument sources
In Christ, Steven Watanabe
On Fri, Jan 12, 2018 at 11:09 AM, Steven Watanabe via Boost < boost@lists.boost.org> wrote:
AMDG
On 01/12/2018 07:47 AM, James E. King, III via Boost wrote:
I cannot build the documentation for Boot.DateTime on the develop tip - I get an error - am I doing something wrong in the command line or is it just broken?
Did you run `b2 headers` first? The glob for the headers is written for the pre-git/release tarball layout.
jking@ubuntu:~/boost/libs/date_time/doc$ ../../../b2 boostdoc Performing configuration checks
- default address-model : 64-bit - default architecture : x86 ../xmldoc/Jamfile.v2:54: in modules.load *** argument error * rule doxygen ( target : sources + : requirements * : default-build * : usage-requirements * ) <snip> * missing argument sources
In Christ, Steven Watanabe
The headers are set up. The rule to collect files is: local date_time_files = [ glob ../../../boost/date_time/*.hpp ] ; I added an echo to print $(date_time_files) it and it is empty. While in the the libs/date_time/xmldoc directory however I can list it fine: jking@ubuntu:~/boost/libs/date_time/xmldoc$ ls ../../../boost/date_time/*.hpp ../../../boost/date_time/adjust_functors.hpp ../../../boost/date_time/date_parsing.hpp ../../../boost/date_time/string_parse_tree.hpp etc... Seems like glob is somehow broken here. Not sure why, yet... - Jim
AMDG On 01/12/2018 09:26 AM, James E. King, III via Boost wrote:
The rule to collect files is:
local date_time_files = [ glob ../../../boost/date_time/*.hpp ] ;
I added an echo to print $(date_time_files) it and it is empty. While in the the libs/date_time/xmldoc directory however I can list it fine:
jking@ubuntu:~/boost/libs/date_time/xmldoc$ ls ../../../boost/date_time/*.hpp ../../../boost/date_time/adjust_functors.hpp ../../../boost/date_time/date_parsing.hpp ../../../boost/date_time/string_parse_tree.hpp etc...
Seems like glob is somehow broken here. Not sure why, yet...
I'll look into it shortly. The use of toolset.using might be suspicious though. (It should be just `using`, but I think if that actually caused a problem it should cause a hard error at the end of the Jamfile.) In Christ, Steven Watanabe
AMDG On 01/12/2018 09:26 AM, James E. King, III via Boost wrote:
The headers are set up.
The rule to collect files is:
local date_time_files = [ glob ../../../boost/date_time/*.hpp ] ;
I added an echo to print $(date_time_files) it and it is empty. While in the the libs/date_time/xmldoc directory however I can list it fine:
jking@ubuntu:~/boost/libs/date_time/xmldoc$ ls ../../../boost/date_time/*.hpp ../../../boost/date_time/adjust_functors.hpp ../../../boost/date_time/date_parsing.hpp ../../../boost/date_time/string_parse_tree.hpp etc...
Seems like glob is somehow broken here. Not sure why, yet...
I can't reproduce your problem with develop (b1193100b09148a4276cbd5455b451e1bb5d5fec) or master (f6ab5fc0fd3d9c3dbd9e3f57595b14d8ae1539fb). Boost.Build: develop 79dd4a729273dcb22a2f1a2340c176863925699b I guess you can try stepping though glob in the debugger. Here's what I see: $ cd libs/date_time/doc $ b2 -dconsole (b2db) break ../xmldoc/Jamfile.v2:26 Breakpoint 1 set at ../xmldoc/Jamfile.v2:26 (b2db) run -n -d1 boostdoc Starting program: /home/swatanabe/bin/b2 -n -d1 boostdoc Performing configuration checks - default address-model : 64-bit (cached) - default architecture : x86 (cached) Breakpoint 1, modules.load ( Jamfile : ../xmldoc/Jamfile.v2 : . ) at ../xmldoc/Jamfile.v2:26 26 local date_time_files = [ glob ../../../boost/date_time/*.hpp ] ; (b2db) break path.glob Breakpoint 2 set at path.glob (b2db) continue Breakpoint 2, path.glob ( ../xmldoc : ../../../boost/date_time/*.hpp : ) at /mnt/hgfs/boost/boost-git/tools/build/src/util/path.jam:219 219 local result ; (b2db) which should give the right results unless something is very wrong. In Christ, Steven Watanabe
AMDG On 01/12/2018 09:26 AM, James E. King, III via Boost wrote:
Seems like glob is somehow broken here. Not sure why, yet...
It's the `toolset.using`. The problem is that importing a module can change the current project, and glob searches relative to the current project. The `using` rule that is implicitly imported into Jamfile modules handles this correctly, but toolset.using does not. It worked for me because I had already set up doxygen in my user-config.jam, which made `toolset.using doxygen ;` a no-op. In Christ, Steven Watanabe
On Fri, Jan 12, 2018 at 12:38 PM, Steven Watanabe via Boost < boost@lists.boost.org> wrote:
AMDG
On 01/12/2018 09:26 AM, James E. King, III via Boost wrote:
Seems like glob is somehow broken here. Not sure why, yet...
It's the `toolset.using`. The problem is that importing a module can change the current project, and glob searches relative to the current project. The `using` rule that is implicitly imported into Jamfile modules handles this correctly, but toolset.using does not. It worked for me because I had already set up doxygen in my user-config.jam, which made `toolset.using doxygen ;` a no-op.
In Christ, Steven Watanabe
Thanks, I'll try to fix that up. How did we generate documentation for 1.66.0 I wonder? :) - Jim
AMDG On 01/12/2018 11:06 AM, James E. King, III via Boost wrote:
Thanks, I'll try to fix that up. How did we generate documentation for 1.66.0 I wonder? :)
user-config.jam: using boostbook ; using doxygen ; Whoever generates the documentation has to have this, because quite a lot of documentation Jamfiles won't work without it. I consider this a bug, but many documentation Jamfiles were written before initializing tools in both user-config.jam and the Jamfile worked correctly, so they require user-config.jam to do all the setup. In Christ, Steven Watanabe
Steven Watanabe wrote:
user-config.jam: using boostbook ; using doxygen ;
Whoever generates the documentation has to have this, because quite a lot of documentation Jamfiles won't work without it. I consider this a bug, but many documentation Jamfiles were written before initializing tools in both user-config.jam and the Jamfile worked correctly, so they require user-config.jam to do all the setup.
I've always thought that it's bad practice to have `using` in Jamfiles rather than `import`. Either one could be made to work, I suppose, and we seem to have tools supporting either idiom; we probably need to pick one and make it official in some way.
AMDG On 01/12/2018 11:41 AM, Peter Dimov via Boost wrote:
Steven Watanabe wrote:
user-config.jam: using boostbook ; using doxygen ;
Whoever generates the documentation has to have this, because quite a lot of documentation Jamfiles won't work without it. I consider this a bug, but many documentation Jamfiles were written before initializing tools in both user-config.jam and the Jamfile worked correctly, so they require user-config.jam to do all the setup.
I've always thought that it's bad practice to have `using` in Jamfiles rather than `import`. Either one could be made to work, I suppose, and we seem to have tools supporting either idiom; we probably need to pick one and make it official in some way.
I prefer using, and I've been adjusting tools to work with it. If a tool works with import in a Jamfile, it's fairly trivial to make using work as well, but the converse is not true. There are a couple of problems with import: - using always calls import first, but we'd really like to skip default configuration if the user gave us explicit options. Setting up a default and then replacing it is possible, but has some technical difficulties when configuration needs to do some kind of global registration (e.g. /zlib//zlib has to add targets to the /zlib project every time you call using). - Jamfiles occasionally need to pass arguments to tool initialization, which import cannot handle. In Christ, Steven Watanabe
participants (3)
-
James E. King, III -
Peter Dimov -
Steven Watanabe