2. I am making a new Boost library or I am using Boost trunk source tree. So add_subdirectory(boost/libs/asio EXCLUDE_FROM_ALL), link to boost::asio
No, the `add_subdirectory` is for a superproject. A library will just call `find_package`(which the superproject will override) to get the targets.
You mean dependency. Like boost is for end user programs. A significant minority of end users will not wish to use find_package() and will strongly prefer to use add_subdirectory(). For example, anyone on Windows will find add_subdirectory() vastly easier going. Anyone who currently integrates Boost into their own build and test config will use add_subdirectory(). Anyone who builds Boost with custom config will use add_subdirectory(). Well written cmake 3 has no problem allowing that. It's now a build driver, any external cmake can load it in and ask it for as much or as little build config as necessary. It's why cmake 3 is so radically better than cmake 2. Stephen did an amazing job in restructuring cmake to be reusable by other cmake. CMakeLists.txt is just a library now, to be consumed by other cmake scripts. If you keep CMakeLists.txt completely free of custom function and macro baggage, your CMakeLists.txt becomes extremely reusable and modular for all other cmake.
You can create header only library targets and >= 3.5 those work right without bugs. You can create static and dynamic library targets for those libraries which implement those.
We need to generate the cmake config package. And that includes the dependencies. Libraries like Hana can “cheat” and export the targets directly to the cmake config package because it has no dependencies. However, for a library like Boost.Fusion the dependencies will need to be listed a third time in the cmake config.
You don't need to generate the cmake config package. cmake generates the cmake config package using its knowledge of how to build the code. I don't know where you're getting all this complexity from. A correct implementation doesn't need anybody to "cheat". It should be 100% modern cmake. If anybody needs to cheat, you've done it wrong.
I would personally suggest a Python script which parses Jamfile.v2 and spits out a CMakeLists.txt. You'd get 80% of Boost.Build easily enough using just this.
We can generate the code with python, which will help with libraries that have lots of dependencies. Although some libraries like Boost.Config is not so simple.
I don't know what you're talking about. cmake tracks dependencies just fine and can export dependencies into things which consume targets.
You just then need to feed everything to the cmake package tooling, again all 100% cmake 3. And you should be done, no cmake innovation needed
The BCM modules aren’t trying to work or redefine the cmake workflow, rather it is tool to help reduce the boilerplate needed to provide cmake support in libraries like boost. Otherwise we will have authors create their own set of functions to make the build scripts more maintainable, and then we will lose consistency among boost libraries.
If there is a single custom function in what is implemented, then it's being done wrong. cmake 3.5 and later comes with substantial runtime facilities obviating the need for macros and custom functions for most end users. Just use what comes built into cmake. I appreciate all the work you've done with the BCM cmake modules. I respectfully insist that all that is superfluous in a minimum viable cmake 3.5 implementation. I appreciate what you are saying about the boilerplate issue, but if you require cmake 3.5 minimum, I do not believe any significant boilerplate issue should occur. (Where the difference between mine and your approach stems from is that cmake is scriptable i.e. you can write programs in cmake which run over a source tree and do housekeeping using "cmake -P" (sometimes "ctest -S" is easier/better). These scripts can talk with git and pregenerate boilerplate that in cmake v2 days would be hidden inside macros. They can also install themselves into githooks so they regenerate boilerplate when you do git checkout and so on. A classic boilerplate to generate is lists of source files to save CMakeLists.txt having to specify it. Another classic cmake script is for Appveyor and Travis run per commit as cmake is portable and actually pretty powerful as a programming language.) So tl;dr; I strongly recommend placing all cmake complexity into runnable scripts which generate .cmake files to be include()d to avoid boilerplate, and keep the CMakeLists.txt etc completely free of any custom macros or functions. This greatly reduces the learning curve for library developers, keeps the cmake clean for end users to import into their cmake, and of course keeps build and configure times very quick. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/