ср, 22 мая 2024 г. в 19:59, Christian Mazakas via Boost
Yup. This is the alternative path. With some elbow grease, we could make b2 a lot better.
Maybe it'd be good if we enumerate our gripes with it so we at least have an outline here.
One of my biggest gripes with it is how permissive it can be in many cases. It'd be nice if there were strict modes where you can require something like zlib and b2 fails if it's not found. Maybe this is already supported but who knows.
If I understand correctly what you are talking about it is in fact Boost's jam scripts make these errors so silent. Essentially, a lot of tests and libraries are defined so that if you do e.g. `b2 cxxstd=03` everything that can't be built with C++ 03 just silently removes itself from the list of targets to build. This is not actually something b2 does. Historically it seemed like a good idea, but as you have noticed, if things don't work as expected, you sometimes miss that. For this reason I added a warning to Boost.JSON for whe `b2 --with-json` is run, but boost_json is skipped. https://github.com/boostorg/json/blob/develop/build/Jamfile#L18-L55
I think it's also a function of documentation and working examples as well.
Error message output also isn't the best with b2 either. I'm thinking about the time I forgot to add a: using asciidoctor ;
to my user-config.jam. b2's output was absolutely unintelligible to me and
I looked it up and "check if you have using asciidoctor anywhere" was literally my first suggestion. To be fair to your point, "unable to construct compat.html, considered these as possible generators:" is not something you would automatically associate with "asciidoctor module was not properly set up", unless you have some experience with b2. Maybe the warning should list the sources, not just the generators it tried.