Re: [boost] [cmake] Minimum viable cmakeification for Boost
Am 20.06.2017 4:21 nachm. schrieb "Peter Dimov via Boost" < boost@lists.boost.org>: Thomas Heller wrote:
As a general observation, I see a lot of statements along the lines of "I state that XYZ is preferable over UVW", it would be nice to have to have background information (pros and cons anyone? what do the cmake authors/docs have to say about this?) on those statements so that everyone can form their own opinion instead of having to choose whom to trust about what's "standard" cmake.
That's the problem with CMake, there's no way for someone like me who does not follow it to get a definitive answer to what idiomatic CMake 3.5+ is. There are several articles about it, they all say more or less the same thing - use target_*. I get that. But that's not enough. I see a general (and very predictable) trend of moving from imperative to declarative. Programmers like imperative, but a proper build system really prefers declarative, so CMake is trying to evolve towards declarative. Take for example find_package. It's a command, find me this package, now. But it's much better if a library does not issue "find me this package" commands, but rather declares which packages it needs. So we get "best practice" hacks like redefining find_package. I'm sorry, this doesn't feel right. I hear what you're saying. We'll end up innovating cmake, which for me isn't a bad thing. I'm favoring CMake due to its great support for generating for all kinds of different environments​ (including proper visual studio solutions). To be fair, I haven't invested as much time in boost.build as I did for cmake. For all platforms I work on, both work equally nice with different quircks on different ends. I'm not using an ide though. For the sake of ide support, I'd lean towards cmake. Regarding the discussion of what's right and wrong when writing your CMakeLists.txt files, it's almost bike shedding. If you want to depend on a library, you'll make it work, no matter what, that's what we do. Nevertheless, in terms of cmakeisms, I really like what Paul put together and what Daniel Pfeifer said in his talk makes a lot of sense in a cmake world. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost
participants (1)
-
Thomas Heller