On Jun 24, 2017, at 3:11 PM, Edward Diener via Boost
wrote: On 6/24/2017 2:53 PM, P F via Boost wrote:
On Jun 24, 2017, at 1:42 PM, Edward Diener via Boost
wrote: On 6/24/2017 1:05 PM, Peter Dimov via Boost wrote:
P F wrote:
https://github.com/pfultz2/boost-cmake-demo/tree/bcm-demo
The library for Boost.System is just:
bcm_boost_package(system VERSION 1.64 SOURCES src/error_code.cpp DEPENDS assert config core predef ) This certainly looks cleaner. It needs to distinguish between public and private dependencies but that's easy to fix. And of course there's the question who will maintain the version and the dependency list.
Shouldn't this be generated on the fly ? The sources are all files in the library's 'src' subdirectory and the dependencies come from your own boostdep. What do you mean generated on the fly? This is stored in each repo so that the user can add the libraries as submodules to their project.
I am saying that this should not have to be maintained manually. That is what I mean by "on the fly". How hard could it be to run some program or Python script which creates such a file for each library automatically ?
I don’t think it would be hard at all. Although, some authors may want to maintain their own cmake, so we don’t want to override the CMakeLists.txt files per-se, and just provide the files such as dependencies.txt and version.hpp, at least from the superproject, since its the only one that knows that information. For source files, we can just have a script that generates the cmake with the source files that the authors can run locally, or the author can update the list(which is fairly easy) or use file globbing if they want.