Re: [boost] [cmake] Pull request announcement

Subject: Re: [boost] [cmake] Pull request announcement
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-09-19 07:40:49

>>> It is very sad that cmake doesn't (AFAIK) support directory scoped target names.
>>
>> It's unnecessary if you're using cmake right.
> 
> I've stopped trying to discern, what is the "right way" to use cmake, but I'm
> Sure it doesn't hurt to be robust against a common way to use cmake. 

Not using import and export of targets is bad cmake, period. It doesn't
scale well, causes maintenance headaches, and most importantly of all,
it's trivially easy to avoid.

You have two choices, low fat and high fat.

Low fat is https://cmake.org/cmake/help/latest/command/export.html. I
generally write a bit of cmake which extracts the targets in the default
build set, and feeds them to export(TARGETS targets... NAMESPACE libname
...). This generates an exported build targets file for exactly one
build configuration. This can be implemented within ten minutes.
Trivially easy.

High fat involves creating an install layout i.e. staging using
https://cmake.org/cmake/help/latest/command/install.html
install(TARGETS). You do this for each build configuration you want. You
then use install(EXPORT) to generate a combined exported build targets
file for many build configurations at once. This takes quite a bit more
effort, I have taken days on this when converting some large projects.

This is the correct way to use cmake. If you're not doing one of the
above, you're doing it wrong.

>> The cmake idiomatic solution is to export those cmake targets from each
>> library which can be externally consumed, during which you can prefix
>> them with a namespace.
> 
> Doing it that way, Is there an easy way to ensure the same compiler flags and 
> definitions are used for all compilations?

INTERFACE_COMPILE_OPTIONS, INTERFACE_COMPILE_DEFINITIONS. Use generator
expression $<BUILD_INTERFACE:...> and $<INSTALL_INTERFACE:...> to
control what gets used at which stage.

> Or the reverse: Is there a way to 
> communicate the available options from the sub-libraries to the super-project
> (e.g. for use in ccmake)? So far I've only used this style with bigger groups of 
> applications/frameworks not on a per-library basis (especially with a tightly 
> coupled group of libraries like boost).

Once a cmake build group is exported, it is written in stone. That's
what makes doing this scalable - the consuming build system can treat it
as a black box.

> Anyway, this is precisely the reason, why my PRs try to stay clear of anything
> more advanced than simple target declaration, static builds and dependency 
> information: Too many possibilities and opinions. This is something I'm
> happy to leave to the cmake professionals and the boost review process 

What you're not getting here is that anything you submit which doesn't
follow cmake idiomatic practice is highly likely to get rejected during
review. So you're wasting your time, unless this is for personal use only.

>> Stephen Kelly outlined all this on here many years ago. And he would
>> certainly know. Search the boost-dev archives.
> 
> Could you be a bit more specific? There is a lot of cmake related discussion in the 
> archives. 
> Was that part of this thread: https://lists.boost.org/boost-build/2016/05/28637.php?

That looks about right.

I was only talking to Steve last Monday in fact. He came to my talk to
the Dublin C++ users group "Deterministic Disappointment". He was
telling me he refuses to touch cmake ever again unless he's getting paid
for it. A nasty addiction it was for him.

Niall