Thinking about it a bit more, what'd be really nice to have is a way to validate .qbk files that could be invoked from Travis/Appveyor, so that we can run that in PRs. But the problem here is that this validator would ideally be written in Python, so as to not require building Quickbook.

On second thought, the idea of rewriting Quickbook in Python is a bit stupid. There is a prebuilt Quickbook in libboost-dev, but it's 1.46 on Ubuntu Precise which Travis uses, so it will not contain our hypothetical strict validation options. We could bite the bullet and build it from source, I suppose. But... D:\tmp2\boost>python2.7.exe tools/boostdep/depinst/depinst.py ../tools/quickbook Installing module core Installing module preprocessor Installing module iterator Installing module algorithm Installing module tuple Installing module bind Installing module smart_ptr Installing module unordered Installing module assert Installing module range Installing module program_options Installing module foreach Installing module filesystem Installing module lexical_cast Installing module config Installing module spirit Installing module iostreams Installing module utility Installing module locale Installing module move Installing module functional Installing module system Installing module tti Installing module concept_check Installing module io Installing module integer Installing module array Installing module regex Installing module static_assert Installing module container Installing module predef Installing module proto Installing module detail Installing module any Installing module type_traits Installing module numeric/conversion Installing module function Installing module tokenizer Installing module random Installing module phoenix Installing module mpl Installing module endian Installing module variant Installing module conversion Installing module fusion Installing module serialization Installing module optional Installing module pool Installing module function_types Installing module exception Installing module thread Installing module typeof Installing module math Installing module throw_exception Installing module type_index Installing module atomic Installing module intrusive Installing module winapi Installing module date_time Installing module chrono Installing module lambda Installing module ratio Installing module rational Hmm. :-)

On 16 March 2017 at 14:29, Peter Dimov via Boost wrote:

There's something wrong with the DIST_BIN logic in Quickbook's Jamfile, because:

It looks like the problem is that 'is-rooted' in 'tools/build/src/util/path.jam' doesn't support windows paths, so 'path.root' in the same file is concatenating absolute paths, giving 'D:\tmp2\boost\D:\tmp2\boost\dist\bin'. But I can't check that as I'm not set up on windows. If I'm right then is-rooted really needs to be fixed, but can you try the attached patch? It assumes that BOOST_ROOT is always absolute, which I think is the case.

On 18 March 2017 at 21:00, Peter Dimov via Boost wrote:

Daniel James wrote:

...

If I'm right then is-rooted really needs to be fixed, but can you try the attached patch? It assumes that BOOST_ROOT is always absolute, which I think is the case.

This works, quickbook gets built and copied to $BOOST_ROOT/dist/bin. But then

C:\Projects\boost-git\boost>dist\bin\quickbook.exe E C:\Projects\boost-git\boost>dist\bin\quickbook.exe --help A C:\Projects\boost-git\boost>dist\bin\quickbook.exe --input-file libs\mp11\doc\mp11.qbk --output-file test.xml G

By the look of it, a UTF-16 string is probably being output as 8 bit. I'll try to debug it. (test.xml does end up being created, so it works, it's just the console output that's missing.)

If the console output isn't working, it'd probably be better to just use ASCII rather than waste time fixing the code (which is very messy). It'll be fine for most output, quickbook will still support UTF-8 in the xml output.

On 18 March 2017 at 21:47, Peter Dimov via Boost wrote:

...

This works, quickbook gets built and copied to $BOOST_ROOT/dist/bin. But then

C:\Projects\boost-git\boost>dist\bin\quickbook.exe E C:\Projects\boost-git\boost>dist\bin\quickbook.exe --help A C:\Projects\boost-git\boost>dist\bin\quickbook.exe --input-file libs\mp11\doc\mp11.qbk --output-file test.xml G

By the look of it, a UTF-16 string is probably being output as 8 bit.

My default toolset is msvc-8.0, and it seems that std::wcout doesn't quite work there, although the trick with _setmode(_fileno(stdout), _O_U16TEXT) does enable wprintf et al.

Looking at the code I expected UTF-16 to work for Visual C++ 7.1 and up, so I'm going to download Visual Studio 2008 and give it a go.

tools\quickbook\src\actions.cpp: In function 'void quickbook::role_action(quickbook::state&, quickbook::value)': tools\quickbook\src\actions.cpp:339:35: error: use of deleted function 'boost::basic_string_ref::basic_string_ref(std::basic_string&&) [with Allocator = std::allocator<char>; charT = char; traits = std::char_traits<char>]' state.phrase.get()); ^ In file included from tools\quickbook\src\fwd.hpp:16:0, from tools\quickbook\src\quickbook.hpp:19, from tools\quickbook\src\actions.cpp:24: ./boost/utility/string_ref.hpp:98:9: note: declared here basic_string_ref( std::basic_string&&) ^~~~~~~~~~~~~~~~

IIRC one of the main use cases for string_ref was so that functions would just need a single overload to accept strings, so that's a bit annoying. I'll wait and see if it changes after the beta.

This looks like the string_ref issue someone already complained about. Your Travis probably missed it because it tests against 1.63.0 instead of depinst.py'ing its way to freedom, democracy and the American way. (Distant bald eagle cry.)

Everything looks like a nail? If i wanted to test against master, I would download a snapshot. But even if I did that, the travis tests wouldn't have caught this, as I only run them in C++03 mode. For a few reasons, I don't think Travis is an appropriate place for testing the dependencies of quickbook. Would be better to add it to the main testing setup, but I've never been motivated enough to do that. My main concern is that the automated builds work, and I'm not going to put a lot of effort into guaranteeing constant support for other configurations.

On 22 March 2017 at 03:00, Peter Dimov via Boost wrote:

I'm more interested in our original topic, that is, there to be a way to validate a .qbk file such that (a) the warning for a missing [endsect] to be an error (and the same applies to other similar warnings, if there are any)

I'm working on it: https://github.com/danieljames/quickbook/commit/68f11c3854b69173f321332f2cfa...

and (b) unmatched [section]/[endsect] in an included .qbk to also be treated the same way if the .qbk marked as self-contained in some unspecified way (not sure that a docinfo block is the best way to mark for our purposes, although I'm not exactly an expert.)

Less of a priority. It's been years since I implemented that warning, and this is the first time that's come up.

On 22 March 2017 at 03:00, Peter Dimov via Boost wrote:

Not sure you should bother with that; I doubt that anyone uses 8.0 any longer (which is 2005 by the way, 2008 is 9.0). I'll bump my default to something modern.

FWIW I installed 2005 but couldn't get it to compile. There's an error in spirit, which is a bit odd, as it's the original spirit which hasn't changed. Seemed to work fine with 2008, but I've changed it (in develop) to not use wide streams for older versions of Visual C++ anyway. I probably should change it to filter out any UTF-8 characters, but they're quite rare in this context, so it should be mostly okay for now.

On 3/27/2017 4:55 AM, Daniel James via Boost wrote:

On 22 March 2017 at 03:00, Peter Dimov via Boost wrote:

...

Not sure you should bother with that; I doubt that anyone uses 8.0 any longer (which is 2005 by the way, 2008 is 9.0). I'll bump my default to something modern.

FWIW I installed 2005 but couldn't get it to compile.

There is also a VS2005 SP1 at https://support.microsoft.com/en-us/help/928957/visual-studio-2005-service-p.... But i would not worry about VS2005 either too much.

There's an error in spirit, which is a bit odd, as it's the original spirit which hasn't changed. Seemed to work fine with 2008, but I've changed it (in develop) to not use wide streams for older versions of Visual C++ anyway. I probably should change it to filter out any UTF-8 characters, but they're quite rare in this context, so it should be mostly okay for now.

On 22 March 2017 at 11:49, Peter Dimov via Boost wrote:

Well currently, "b2 doc" would fail for everyone using Visual Studio 2013/2015/2017 or g++ 6. It would have failed for me had I not been using the ancient 8.0 as a default.

Then they file a bug report, and I fix it at a leisurely pace, suggesting they use a binary from the last release that worked. It's not ideal, but that's life for you.

In general, and this is not directed at you personally, the point of testing develop against boostorg:develop is to catch such breaking changes as the current string_ref one early, before they reach the release. Downstream dependencies effectively serve as an integration test for lower-level libraries.

Travis is an awful mechanism for doing that as it only runs when there's a commit to the submodule being tested, which might not be regular. As it happens, the change to string_ref that caused this issue was on the 13th of February, the last commit to quickbook before you reported this was on the 12th of February.

On 22 March 2017 at 22:14, Peter Dimov via Boost wrote:

Daniel James wrote:

...

Travis is an awful mechanism for doing that as it only runs when there's a commit to the submodule being tested, which might not be regular.

It's a stochastic testing method, three time winner of the highly acclaimed "still better than nothing" award.

It's a negligible difference.

There is a prebuilt Quickbook in libboost-dev, but it's 1.46 on Ubuntu Precise which Travis uses, so it will not contain our hypothetical strict validation options. We could bite the bullet and build it from source, I suppose. But...

On further reflection, the obvious way to make Quickbook available for Travis/Appveyor builds is to just publish binaries using the Github release system. We'll still need a way to enable "strict mode" though, either from within the document, or via a command line option.

Daniel James wrote:

...

On further reflection, the obvious way to make Quickbook available for Travis/Appveyor builds is to just publish binaries using the Github release system.

Perhaps something like this?

https://github.com/boostorg/website/blob/master/.travis.yml#L13

Something like this :-)