Moving CMake forward
Man but there's been a lot of hot air expanded on this subject.... guys if we're going to do this, just do it. We're empiricists around here: lets see what the proponents of CMake can come up with, yes I know there are straw man proposals, but I want something that demonstrates it can fully handle the complex cases at least as well as Boost.Build, and be maintainable by CMake ignorants like myself, because lets face it, once the transition is over, library authors will have to do the maintenance grunt work as before: and if we can't easily see how to do that, then the project probably fails. As a minimal first step, what I would like to see come up for review (yes a review folks!) is a system that: * Provides users with a way to build those libraries with source via CMake. All of them together, or just some subset. * Provides an install option for all of Boost. * Is trivially easy for non-CMakers like myself to maintain. Documentation should be provided (Boost/CMake best practice is...). * Is fully compatible with current auto-linking naming on Windows (plus whatever else comes along later like address-model and architecture name mangling that's in the works and has long been requested). * Supports libraries with non-trivial build requirements (regex, locale, what others?). * Is usable by end users to be able to easily reference Boost libraries from their own CMake projects (note, might be limited to libraries with source, since header only libraries are kind of trivial). An example, and how to documentation should be provided. * It would be nice if generated VS projects were reference-able from our own solutions as well, but I accept that may not be possible. * Is at a minimum, no worse than what we have now. What else? Takers? BTW, I don't see a need for this to encompass every Boost library with source before some kind of mini-review to iron out the warts... Just hoping to move things along, John. --- This email has been checked for viruses by AVG. http://www.avg.com
Le 22.07.17 à 11:07, John Maddock via Boost a écrit :
Man but there's been a lot of hot air expanded on this subject.... guys if we're going to do this, just do it. We're empiricists around here: lets see what the proponents of CMake can come up with, yes I know there are straw man proposals, but I want something that demonstrates it can fully handle the complex cases at least as well as Boost.Build, and be maintainable by CMake ignorants like myself, because lets face it, once the transition is over, library authors will have to do the maintenance grunt work as before: and if we can't easily see how to do that, then the project probably fails.
As a minimal first step, what I would like to see come up for review (yes a review folks!) is a system that:
* Provides users with a way to build those libraries with source via CMake. All of them together, or just some subset.
* Provides an install option for all of Boost.
* Is trivially easy for non-CMakers like myself to maintain. Documentation should be provided (Boost/CMake best practice is...).
* Is fully compatible with current auto-linking naming on Windows (plus whatever else comes along later like address-model and architecture name mangling that's in the works and has long been requested).
* Supports libraries with non-trivial build requirements (regex, locale, what others?).
* Is usable by end users to be able to easily reference Boost libraries from their own CMake projects (note, might be limited to libraries with source, since header only libraries are kind of trivial). An example, and how to documentation should be provided.
* It would be nice if generated VS projects were reference-able from our own solutions as well, but I accept that may not be possible.
* Is at a minimum, no worse than what we have now.
What else?
Takers?
I am in. I have several things in mind, such as * to work on an component that describes the dependencies between libraries in order to add then in a topological sort order from the main project * port the documentation generation, focus quickbook+doxygen at first * think/design/adapt/deploy regression runners and a possibly new regression dashboard How do you want to interact? Raffi PS: for the record, I am not a proponent/opponent of cmake/b2, I am proficient in cmake though.
I am in. I have several things in mind, such as
* to work on an component that describes the dependencies between libraries in order to add then in a topological sort order from the main project * port the documentation generation, focus quickbook+doxygen at first * think/design/adapt/deploy regression runners and a possibly new regression dashboard
All nice to have, but too advanced for me right now given that we have a working system for those already... the priority is to improve the end users experience, and keep the initial step focused enough that we can review it and polish it up for release without getting bogged down and/or acrimonious about it.
How do you want to interact?
To repeat, I have zero knowledge of CMake and am rather happy with what we have. However, as a born-again-empiricist-scientist type I am open to being proved wrong. So I'm more than happy to test whatever folks come up with, but maybe before even that point, I'd like to be able to read the equivalent of Boost's current getting started docs written for a CMake port of the build/install process. After that, some getting started docs for library authors too. I guess that's what I'm missing from the current discussion - it's either too technical for me to follow because I'm not familiar with CMake's internals, or else too advocacy-based and substance free. I'm looking for something that can be fed to a willing guinea pig so we can see if he prospers or not ;) John.
Raffi
PS: for the record, I am not a proponent/opponent of cmake/b2, I am proficient in cmake though.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost .
--- This email has been checked for viruses by AVG. http://www.avg.com
Le 22.07.17 à 12:51, John Maddock via Boost a écrit :
I am in. I have several things in mind, such as
* to work on an component that describes the dependencies between libraries in order to add then in a topological sort order from the main project * port the documentation generation, focus quickbook+doxygen at first * think/design/adapt/deploy regression runners and a possibly new regression dashboard
All nice to have, but too advanced for me right now given that we have a working system for those already... the priority is to improve the end users experience, and keep the initial step focused enough that we can review it and polish it up for release without getting bogged down and/or acrimonious about it.
mmm... ok.
How do you want to interact?
To repeat, I have zero knowledge of CMake and am rather happy with what we have. However, as a born-again-empiricist-scientist type I am open to being proved wrong. So I'm more than happy to test whatever folks come up with, but maybe before even that point, I'd like to be able to read the equivalent of Boost's current getting started docs written for a CMake port of the build/install process. After that, some getting started docs for library authors too. I guess that's what I'm missing from the current discussion - it's either too technical for me to follow because I'm not familiar with CMake's internals, or else too advocacy-based and substance free. I'm looking for something that can be fed to a willing guinea pig so we can see if he prospers or not ;)
John.
I understand your points. I however feel like this is a bit of a "chicken and egg" situation: for instance, I fail to understand how one can write an how-to for library authors, without even having a tiny set of representative libraries that have proven the concept (or cmake API). Also, it is not like you (personally) know nothing about build system. Even though you have no experience with cmake, you have some (even good) with b2, and you understand the problems those build system address. This makes me wonder what is the level of assumptions we can make in order to write a guide. So, what I suggest is this: 1. we take one/two good developers as a target, including you for instance. You are the user in this case, and a group of cmake developers should provide you with a way to express your build requirements for a set of libraries of your choice. The library should not be trivial to port though (for instance should not be header only and should have other dependencies), otherwise this would be useless for most of us. 2. you review and interact with the cmake port developers, trying to port eg. another library with the tools that were developed in the first stage. If this is too complicated/difficult/error prone, then we go back to 1. 3. once everybody is happy (or not) we write one tentative how-to and report back to the ML. On my side, I will mostly try to do what is being done with b2 for boost.test. (Although some people do not like it) it is a central library I believe, and its integration to other project will raise a lot of issues. What do you think? Raffi
So, what I suggest is this:
1. we take one/two good developers as a target, including you for instance. You are the user in this case, and a group of cmake developers should provide you with a way to express your build requirements for a set of libraries of your choice. The library should not be trivial to port though (for instance should not be header only and should have other dependencies), otherwise this would be useless for most of us. 2. you review and interact with the cmake port developers, trying to port eg. another library with the tools that were developed in the first stage. If this is too complicated/difficult/error prone, then we go back to 1. 3. once everybody is happy (or not) we write one tentative how-to and report back to the ML.
Sounds reasonable to me.
On my side, I will mostly try to do what is being done with b2 for boost.test. (Although some people do not like it) it is a central library I believe, and its integration to other project will raise a lot of issues.
What do you think?
Raffi
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
--- This email has been checked for viruses by AVG. http://www.avg.com
On 07/22/17 12:07, John Maddock via Boost wrote:
Man but there's been a lot of hot air expanded on this subject.... guys if we're going to do this, just do it. We're empiricists around here: lets see what the proponents of CMake can come up with, yes I know there are straw man proposals, but I want something that demonstrates it can fully handle the complex cases at least as well as Boost.Build, and be maintainable by CMake ignorants like myself, because lets face it, once the transition is over, library authors will have to do the maintenance grunt work as before: and if we can't easily see how to do that, then the project probably fails.
As a minimal first step, what I would like to see come up for review (yes a review folks!) is a system that:
* Provides users with a way to build those libraries with source via CMake. All of them together, or just some subset.
* Provides an install option for all of Boost.
* Is trivially easy for non-CMakers like myself to maintain. Documentation should be provided (Boost/CMake best practice is...).
* Is fully compatible with current auto-linking naming on Windows (plus whatever else comes along later like address-model and architecture name mangling that's in the works and has long been requested).
* Supports libraries with non-trivial build requirements (regex, locale, what others?).
Boost.Log, please. :) It has quite a lot of configuration and autodetection.
* Is usable by end users to be able to easily reference Boost libraries from their own CMake projects (note, might be limited to libraries with source, since header only libraries are kind of trivial). An example, and how to documentation should be provided.
* It would be nice if generated VS projects were reference-able from our own solutions as well, but I accept that may not be possible.
* Is at a minimum, no worse than what we have now.
What else?
Takers?
BTW, I don't see a need for this to encompass every Boost library with source before some kind of mini-review to iron out the warts...
Just hoping to move things along, John.
2017-07-22 18:07 GMT+09:00 John Maddock via Boost
(snip)
As a minimal first step, what I would like to see come up for review (yes a
review folks!) is a system that:
(snip) * Is usable by end users to be able to easily reference Boost libraries from their own CMake projects (note, might be limited to libraries with source, since header only libraries are kind of trivial). An example, and how to documentation should be provided.
You can create a virtual target called INTERFACE then users can reference that target to get all the dependencies for the header files: set(BOOST_INCLUDE_DIR "${PROJECT_SOURCE_DIR}/include")
add_library(boost_all_headers INTERFACE) file(GLOB_RECURSE BOOST_ALL_HEADERS "${BOOST_INCLUDE_DIR}/include" "*.hpp") target_include_directories(boost_all_headers INTERFACE "${BOOST_INCLUDE_DIR}") target_sources(boost_all_headers INTERFACE ${BOOST_ALL_HEADERS}) install(TARGETS boost_all_headers EXPORT boost_all_headers_export) export( EXPORT boost_all_headers_export FILE "Boost-config.cmake" )
Basically you put this kind of script to the root CMakeLists.txt (of Boost). The steps for the user could be something like: - Clone the boost library (or its components). - Run the initial `cmake` for boost. - Run `make install` - when you have provided some specific options to CMake, this won't actually *install*; it does the EXPORTing and creates the Boost-config.cmake on the Boost root. So if you need only the header-only library, then you can just generate the exported target without building the libs. Referencing the exported target should also correctly add the Boost include directory (pointing to your local installation) to your program. Sometimes you need the BEFORE PUBLIC property to get it included before the system-wide dirs. The script above is a rough sketch, but I hope this helps.. Nana.
On 7/22/2017 5:07 AM, John Maddock via Boost wrote:
Man but there's been a lot of hot air expanded on this subject.... guys if we're going to do this, just do it. We're empiricists around here: lets see what the proponents of CMake can come up with, yes I know there are straw man proposals, but I want something that demonstrates it can fully handle the complex cases at least as well as Boost.Build, and be maintainable by CMake ignorants like myself, because lets face it, once the transition is over, library authors will have to do the maintenance grunt work as before: and if we can't easily see how to do that, then the project probably fails.
As a minimal first step, what I would like to see come up for review (yes a review folks!) is a system that:
* Provides users with a way to build those libraries with source via CMake. All of them together, or just some subset.
* Provides an install option for all of Boost.
* Is trivially easy for non-CMakers like myself to maintain. Documentation should be provided (Boost/CMake best practice is...).
* Is fully compatible with current auto-linking naming on Windows (plus whatever else comes along later like address-model and architecture name mangling that's in the works and has long been requested).
* Supports libraries with non-trivial build requirements (regex, locale, what others?).
* Is usable by end users to be able to easily reference Boost libraries from their own CMake projects (note, might be limited to libraries with source, since header only libraries are kind of trivial). An example, and how to documentation should be provided.
* It would be nice if generated VS projects were reference-able from our own solutions as well, but I accept that may not be possible.
* Is at a minimum, no worse than what we have now.
What else?
Testing and documentation with CMake. This covers nearly all libraries which test, as well as a large subset of libraries which use b2 to create the library documentation.
Takers?
BTW, I don't see a need for this to encompass every Boost library with source before some kind of mini-review to iron out the warts...
Just hoping to move things along, John.
Exactly. CMake as the required build system for Boost is a done deal and we are wasting much hot air arguing about, even if we understand the reasons for that hot air. I fully support settings practical use cases and moving forward addressing those use cases for the people who understand CMake and can make things happen.
participants (5)
-
Andrey Semashev -
Edward Diener -
John Maddock -
Nana Sakisaka -
Raffi Enficiaud