cps-org / cps-org/cps

[proposal] Conditional flags based on the consumer compiler

Open
#112 6 comments 1 reaction 0 assignees View on GitHub
Dominant language
Python
Stars
191
Forks
14
PR merge metrics
No merged PRs in 30d

Description

There are many cases of open source third party libraries that require to activate certain flags, like C++ flags, in order to let the consumers to correctly use and link with them.

A common use case is the definition of ``/Zc:__cplusplus`` flag, because some conditionals in headers use the ``__cplusplus`` value to enable, disable certain features or APIs.

In ConanCenter, I can find around 40 different recipes that have the idiom ``if msvc => Define /Zc:__cplusplus``, with some notorious libraries like llvm-openmp, ffmpeg, libgettext, mlpack, ncurses and swig.

The main problem here is compatible binaries. A given binary can be compiled for example with ``clang``, and then it might be consumed and linked both by different end users, some using ``msvc`` compiler and some using ``clang`` compiler (with msvc binary-compatible backend).

Consequently, it is not possible to unconditionally define those compiler flags for a given package ``.cps`` file.

The current CPS ``compile_flags`` are discouraged because of this fact, but it defines that a mapping can be defined for different languages:

```
A map may be used instead to give different values depending on the language of the consuming source file.
Handling of such shall be the same as for [definitions](https://cps-org.github.io/cps/schema.html#definitions).
```
Same happens for CPS ``link_flags``.

The situation is similar to the CPS ``definitions``, that also allows a possible mapping based on the language.

I think this scenario is not so niche to not be supported by the spec, and then I'd suggest to define a mapping that allows to conditionally define flags depending on the consumer compiler, something like:
```json
{
"compile_flags": {
"msvc": ["/Zc:__cplusplus", ...]
"gcc": [...]
}
}
```

Otherwise, we will have a bunch of massively popular C and C++ open source libraries that will fail to be consumed via CPS out of the box, as they will fail due to the lack of correct ``__cplusplus``.

I am happy with actively discouraging the definition of ``compile_flags`` and ``link_flags`` for most cases, I totally agree on that, but there might be situations that will be quite painful if not allowed and supported by the spec, with major library maintainers not willing to adopt CPS because their users will complain because it doesn't work seamlessly in MSVC, for example.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.