Re: [boost] [cmake] Minimum viable cmakeification for Boost

Subject: Re: [boost] [cmake] Minimum viable cmakeification for Boost
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2017-06-21 11:54:52

On 06/21/2017 12:58 PM, Peter Dimov via Boost wrote:
> Thomas Heller wrote:
> 
>> People who prefer declarative builds can stick to Boost.Build.
> 
> That's missing the point. Declarative build descriptions are preferable
> in any build system, and any serious use of one leads inevitably to this
> same conclusion. Witness, for instance, how Meson intentionally makes
> its language not Python, even though it's very much Python-looking, and
> how Bazel also has its own language. This is because if the language is
> Python, people are encouraged to program in it, instead of declaring
> targets.
> 
> Target declarations compose, logic that manipulates global environment
> doesn't.
> 

I totally get that a declarative build system is superior. The quote was
taken out of context (or I didn't express my intent clearly).
The thing is that we already have a declarative build system
(Boost.Build). People want to interface with CMake though (which is only
very slowly catching up with the declarative stuff), and I assume that
most CMake scripts out in the wild are *not* in the declarative
paradigm, and it takes to get accustomed to it. Yet, there are a lot of
people complaining that Boost is "asocial" because it doesn't interface
well with the predominant build plan generator out there. Since CMake is
moving more and more towards being declarative, the gap seems to close
and we could build a bridge. Or just advertise Boost.Build more
prominently so it isn't seen as the odd one in the block, but the goto
solution.

> Now it's true that the declarative approach is sometimes less
> convenient. Imperatively, you just check whether zlib is installed,
> #define or not HAVE_ZLIB and build different things based on that.
> Whereas the alternative is to have a separate zlib-support library
> target, which injects a .cpp file into the main program via
> usage-requirements, which registers the zlib support with the main
> library. But, the upside is that if everyone writes their build
> descriptions properly, you just link to the appropriate targets in the
> root build file and everything "just works".

FWIW, this is totally doable within CMake. Consider this:

# I guess this if statement has to persist, if someone knows a way
# around it, please fix. Could be placed in another Setup.cmake or so to
# seperate the build logic from this logic.
if (PUMPKIN_WITH_ZLIB)
# This sets ZLIB_FOUND to TRUE if found and exports and gives you the
# ZLIB::ZLIB target.
  find_package(ZLIB)
else()
# Workaround to have the target available even when zlib was not
# requested...
  add_library(ZLIB::ZLIB INTERFACE IMPORTED)
endif()

# Sets up the zlib dependent target...
add_library(pumpkin_zlib
    EXCLUDE_FROM_ALL ${PUMPKIN_ZLIB_SOURCES})
target_compile_definitions(pumpkin_zlib PUMPKIN_HAVE_ZLIB)
target_link_libraries(pumpkin_zlib ZLIB::ZLIB)

# setup the main target.
add_library(pumpkin ${PUMPKIN_SOURCES})
target_link_libraries(pumpkin
    PRIVATE $<$<BOOL:${PUMPKIN_WITH_ZLIB}>:pumpkin_zlib>)

And yes, the syntax is horrible ;)
The generator expressions are the way to achieve proper declarative
build logic, I presume. This whole option and find_package thingy is
boilerplate which could be put in a common place to give the impression
on having no if statements in the module CMakeLists.txt :P

> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost