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 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</.../libs/date_time/xmldoc> : ../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

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

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.

James E. King, III wrote:

Thanks, I'll try to fix that up. How did we generate documentation for 1.66.0 I wonder? :)

By having a user-config.jam with `using doxygen ;` in it would be my guess. :-)