Remove bob.cmake from coding convention

[castigli]

I propose to remove bob.cmake from the coding conventions.
The main reasons are the following

• it bypasses the cmake way to handle flags
• it makes it harder to understand what is being set
• it makes it more difficult to change flags manually
• it goes against the modern cmake approach of having target specific settings

[tristan0x]

This file comes from trilinos/omega_h + custom stuff or ours.
You are free to not use it like omega_h and some of BBP's projects are doing to declare the build targets but still use some of the public functions like the bob_cxx_pedantic_flags that provides the C++ flags that every C++ project at BlueBrain must use.

[castigli]

If it is in the coding convention, it seems more like you should use it more than being free to use it.

... still use some of the public functions like the bob_cxx_pedantic_flags that provides the C++ flags that every C++ project at BlueBrain must use.

I disagree that all projects and all targets should have, for instance -Werror enabled all the time.
Additionally all these flags are hidden, so that you cannot even easily modify them from the cmake gui/command line. To me it seems like a very bad practice.

[matz-e]

Additionally all these flags are hidden, so that you cannot even easily modify them from the cmake gui/command line.

I spent some time in the last deployment hunting down changed default settings for compiler flags that upset -Werror. Not a fan of having this buried in a submodule, and behind a chain of function calls.

[pramodk]

IIRC, this topic was briefly touched in the past as well.

@tristan0x : if bob.cmake is integrated into project, almost 99% of "normal" CMake users don't understand what's going on. From my past experiences, it adds more confusion that it's benefit. So I would be also in favour some other mechanisms to achieve functionality we would like to have instead of bob.cmake.

[tristan0x]

There are many topic touched in this ticket.

• bob is currently used. So as long as there is not something else to achieve the same thing, it should not be removed. The question is not to remove bob but what to provide instead to handle the compilation flags in a consistent way across all C++ projects using the compilation flags mentioned in the coding conventions.
• The fact that @castigli doesn't want -Werror to be activated all the time is independent of bob. -Werror is part of the BlueBrain coding conventions, and I completely disagree that it should be globally removed because it can lead to code quality decrease, but this topic should be discussed in another ticket anyway.

[castigli]

bob is currently used. So as long as there is not something else to achieve the same thing, it should not be removed. The question is not to remove bob but what to provide instead to handle the compilation flags in a consistent way across all C++ projects using the compilation flags mentioned in the coding conventions.

Not everything being used in every project is part of the coding conventions...

The fact that @castigli doesn't want -Werror to be activated all the time is independent of bob. -Werror is part of the BlueBrain
coding conventions, and I completely disagree that it should be globally removed because it can lead to code quality decrease, but this topic should be discussed in another ticket anyway.

Perhaps I didn't express myself clearly, but I didn't want to suggest to remove -Werror everywhere. I agree that during development/CI testing it should be enabled, but there should be a way to disable it easily (and ideally disabled to shipped code). We are not testing for all possible combination of libraries/compilers.
It is a recognized bad practice to ship something that easily break, I am just trying to improve the code and the experience of users/developers not impose my view.
This issue is very much related to bob.cmake since it adds flags bypassing the standard cmake usage.

[ohm314]

We discussed this issue today extensively within the team. Here's a brief summary:

• It looks like bob is not being used for anything providing the compile flags.
• Beyond this, the bob-method of providing those flags is only done in a few projects.
• The consensus is that bob is very hard to understand, let alone to be maintained or extended. This is also the reason why from everyone who attended, no one wants to use it in their project (not even as part of hpc-coding-conventions).
• The missing functionality, if bob were removed should be instead added into hpc-coding-conventions as needed and using simple cmake files without complex inter-dependencies. The reasoning is that these scripts can then also be used in projects we maintain that do not use hpc-coding-conventions (e.g. NEURON, HighFive).
• If there is a project that extensively uses bob, it is of course free to continue use it in its own build-system.

The conclusion is that bob should be removed and whatever is missing replaced by something simpler to maintain and more modular.

The first step is to find out what is really used from bob. In this discussion above I see bob_cxx_pedantic_flags. What else?

CC: @tristan0x @pramodk