Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[proposal] Conditional flags based on the consumer compiler

Open
  • Is something wrong?
#112 6 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
40/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
cpp
Domain
build-system, tooling

Research direction

Start with the CPS schema sections for compile_flags, link_flags, and definitions, including their language-based mappings. Compare the proposed consumer-compiler mapping with those rules and document the expected behavior for MSVC and GCC/Clang consumers; the work is done when the specification resolves these conditional flags without making compatible binaries unusable.

Written by the indexing model from the issue text.

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:

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

Dominant language
Python
Stars
191
Forks
14
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from cps-org/cps

All issues in cps-org/cps

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.