Skip to content

[proposal] Conditional flags based on the consumer compiler #112

@memsharded

Description

@memsharded

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:

{
    "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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions