On 19/07/2017 23:14, Edward Diener via Boost wrote:
On 7/19/2017 4:46 PM, Oliver Kowalke via Boost wrote:
As mentioned before - it is not only your cmake port, all presented boost-cmake files have ported only fraction of the required functionality. For instance feature tests used in Jamfile to test for presence/absence of some C++ features to control the build. If it's so easy to do it with Cmake I'm wondering why it wasn't done. I've the impression that only the easy parts of Jamfile have been ported. The difficult parts are left ...
Boost Build has the ability to run a 'program' and change the logic of what is to be built, or how something is to be built, based on the return value of that program. I do not know CMake well enough but I am assuming that CMake also has such a feature, else it would really be deficient IMO. That is essentially what Boost Config offers and Boost Predef offers and my briefly discussed Cxxd library also offered, through the facility in Boost Build which allows this. Porting Boost Config and Boost Predef to use CMake would have to port this ability also in an easy to use way, since other libraries also depend on the Boost Config and Boost Predef facilities when they use Boost Build for their purposes.
This is indeed possible: https://cmake.org/cmake/help/v3.8/command/try_compile.html#command:try_compi... Usually, you don't need to run them since you might be cross compiling for a weird platform and can't run programs for it, so it's better if the check can be done at compile time. If you just want to check a header exists or just symbols, there are some other dedicated functions too that are a bit more convenient.
As Klemens already mentioned, I'm missing a discussion about the requirements of the boost build system and a comparison of pros/cons of other build systems on the ML.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost