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