[1.56] Getting the release back on track - build errors
There are several build errors when building current master, for this test I used Mingw64: * Context fails to build complaining about ml64 not being found, but since I'm building with gcc it really should be using as? * Thread fails to build complaining about missing boost/utility/detail/result_of_iterate.hpp, this is a result of: #define BOOST_PP_ITERATION_PARAMS_1 (3,(0,BOOST_RESULT_OF_NUM_ARGS,<boost/utility/detail/result_of_iterate.hpp>)) In boost/utility/result_of.hpp, we could presumably fix this by adding a dependency that Boost.Build can actually track to this header. Presumably we should do the same for all header iterations? * Coroutine fails for the same reason as thread. * Header only libraries are not installed when doing a build/stage/install all, you have to explicitly invoke b2 headers. IMO this will trip a lot of folks up. * There is no mention of the "b2 headers" option from "b2 --help". Question - I assume that if folks do a library-specific install then we *don't* want to install all headers? Can we achieve that and yet make the equivalent of "b2 headers" happen if folks do a build all? Cheers, John.
2014-07-02 20:28 GMT+02:00 John Maddock <jz.maddock@googlemail.com>:
* Context fails to build complaining about ml64 not being found, but since I'm building with gcc it really should be using as?
At the moment boost.context supports only masm64 on 64bit Windows - because mams comes with macros installing/generating the exception tables. Using GNU as would require to port the masm syntax to GNU as and generating the exception table entries by hand.
On Wednesday 02 July 2014 19:28:07 John Maddock wrote:
There are several build errors when building current master, for this test I used Mingw64:
* Thread fails to build complaining about missing boost/utility/detail/result_of_iterate.hpp, this is a result of:
#define BOOST_PP_ITERATION_PARAMS_1 (3,(0,BOOST_RESULT_OF_NUM_ARGS,<boost/utility/detail/result_of_iterate.hpp>) )
In boost/utility/result_of.hpp, we could presumably fix this by adding a dependency that Boost.Build can actually track to this header. Presumably we should do the same for all header iterations? * There is no mention of the "b2 headers" option from "b2 --help".
Question - I assume that if folks do a library-specific install then we *don't* want to install all headers? Can we achieve that and yet make the equivalent of "b2 headers" happen if folks do a build all?
For reference, there is this pull request: https://github.com/boostorg/utility/pull/17 with the relevant discussion. To my understanding, 1.56 will be a non-modular release which means that the distributed archives will include the complete boost/ directory along with all libraries. Therefore users won't need to invoke 'b2 headers' themselves to be able to build and use Boost. Is my understanding correct?
On Jul 5, 2014, at 6:01 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
To my understanding, 1.56 will be a non-modular release which means that the distributed archives will include the complete boost/ directory along with all libraries. Therefore users won't need to invoke 'b2 headers' themselves to be able to build and use Boost. Is my understanding correct?
Yes, your understanding is correct. — Marshall
participants (4)
-
Andrey Semashev -
John Maddock -
Marshall Clow -
Oliver Kowalke