On 10/15/2018 4:36 PM, Roger Leigh via Boost wrote:
On 10/10/18 15:23, Edward Diener via Boost wrote:
On 10/10/2018 4:44 AM, Roger Leigh via Boost wrote:
This is all supported by CMake for years as mike said, and it's utterly trivial to write such feature tests. If you would like some examples, here's some I wrote for Xerces-C++:
[examples]
I don't think any of this is difficult. If anything, you can likely reuse the existing source code used by the Boost.Build checks, maybe even sourced directly without any changes--just wrap it with check_cxx_source_compiles or other feature test macros.
My point is that you can not ask each library maintainer to re-invent what he already uses from Boost config and/or Boost predef. You need to reprogram this in CMake for each case in config and predef, and then provide a CMake-like interface to it for other libraries. I do not care how easy you find it in CMake, individual library maintainers are not going to spend time re-duplicating everything they need from config and predef just so they can build their library and/or run their library tests. We are talking about some 130+ potential Boost libraries we have to deal with, and any conversion to CMake that is non-trivial is going to be very unpopular.
The logic could be written to be either in a single place (which can provide CMake logic for other components to use), or duplicated in the different components. Which is better depends upon how decoupled you wish the components to be. If you always require a monolithic build, then one component could provide shared functionality. Otherwise, duplication is better to avoid tight coupling. As an example:
https://gitlab.com/rleigh/ome-common-cpp/tree/master/cmake
are modules I routinely share between related components of a larger project. Not the size of Boost though.
Nearly every library depends on Boost.Config. Boost.Predef was created much, much later than Boost.Config so I do not know how many libraries use its functionality. Creating support for Boost.Config check builds should be done once in Boost.Config and creating support Boost.Predef check builds should be done once in Boost.Predef. Expecting individual libraries to duplicate what is current in those libraries, for CMake, is not something the maintainers of those other libraries will want to do.
I looked at the Boost config and predef links Rene provided in another email in this thread.
The Boost.Config checks all look pretty straightforward. Should be possible to iterate over them and store each one in a variable, then we could provide them in the exported configuration for dependent components to consume.
(While I see this component does have CMake support merged in, I don't see any configuration export. Where is that handled? Has anyone worked on it yet?)
For Boost predef this isn't much different; run the program and store the results, export the variables.
In both cases, CMake users can then simply run conditional logic such as:
if (boost_feature) list(APPEND sources foo.cpp) endif()
or
if (boost_feature2 AND boost_feature3 AND NOT boost_feature 4) add_executable(foo …) … endif()
and so on.
Note that a number of the predef checks are already supported directly by CMake, such as if(MSVC) if(WIN32) etc. While the predef checks can be carried over for completeness, they are not necessary.
I would be happy to work on some of this. I'm not sure exactly how to do so however. Where would I submit it? Is CMake development discussion happening on any other lists or other places? I don't want to tread on any toes or work at cross-purposes.
It would be best to mention that you would like to help convert the check builds functionality in those two libraries to CMake on the appropriate library's Github page. You could bring this up as Issues for each of the two libraries and eventually create PRs.
Regards, Roger