On 4/14/16 8:50 AM, Louis Dionne wrote:
Rene Rivera
writes: On Wed, Apr 13, 2016 at 6:00 PM, Robert Ramey
wrote: On 4/13/16 3:37 PM, P F wrote:
The CMakeLists.txt file should be in the top-level directory.
Hmmmm - says who? I realize that this is the common way to do it. But it ends up sprinkling CMakeList.txt files all over the place. Doing it the way I've done makes supporting CMake much less intrusive and leaves the "footprint" of CMake support on par with build (boost build) easily permitting the user to select which he prefers.
http://www.boost.org/development/requirements.html#Organization
I think this recommendation is out of line with current practice. From my experience, the top level CMakeLists.txt file is almost always expected to appear at the root of the project. Out of the 25 most trending C++ projects this month on GitHub,
That may be true. But doing it in this way is very intrusive and conflicts with fundamental aspects of the boost way of doing things. But I always respect convention - except when I don't.
- 8 use CMake as a primary build tool - out of those, 7 have a CMakeLists.txt file at the root of the project
Actually I'm guessing that these projects support CMake as the only build tool. But that's just a guess
Unfortunately, there does not seem to be agreement about what build system to use (many use plain Makefiles), but among the ones that use CMake, agreement is on the CMakeLists.txt file being at the top level. Other notable projects that use CMake and include the CMakeLists.txt file at the root are Facebook's HHVM and Kitware's CMake itself. An example [1] on CMake's website also suggests doing this.
I don't agree with the work "Unfortunately". Actually I don't agree with the "Un". One of the key features of boost is that it tries to impose only the minimum requirements required to fulfill it's mission. Over the last 15 years we've seen huge evolution in build systems, documentation systems, social communication, etc. Our system has permitted this evolution to occur without upending all the components are making us spend huge amount of time in maintenance. In the places were to do work hard to get conformity, documentation, build systems, we get huge pushback from library authors who want to do things their own way. (e.g. DOxygen documentation).
Finally, FWIW, I think all the CMake-powered projects I've seen so far also put the top level CMakeLists.txt file at the root (but that is just my experience).
Another very, very, very bad idea. This conflicts in a fundamental way with the goal of modularization. It couples all the libraries together through the build system. This kind of coupling is the biggest single feature which makes it harder to support a growing set of Boost libraries.
Personnally, I will need something more authoritative than the requirement page you link above to be convinced of putting the CMakeLists.txt file in another place than the root of the project.
LOL - Boost is pretty easy - you pretty much have the right do whatever isn't specifically prohibited - even if it's a bad idea. What you don't have the right to do is to put something in the boost root or in some other library just to implement some preference in your own library. Robert Ramey
Regards, Louis Dionne
[1]: https://cmake.org/examples/
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost