Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable setting C/C++ standards as a toolchain feature #16551

Open
jungleraptor opened this issue Oct 26, 2022 · 6 comments
Open

Enable setting C/C++ standards as a toolchain feature #16551

jungleraptor opened this issue Oct 26, 2022 · 6 comments
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) team-Rules-CPP Issues for C++ rules type: feature request

Comments

@jungleraptor
Copy link
Contributor

jungleraptor commented Oct 26, 2022

Description of the feature request:

Proposal to add a handful of new "features" to the default c++ toolchain that enables setting C/C++ standards (names tentative):

  • default_cxx_standard (respects BAZEL_CXXOPTS, default -std=c++0x)
  • cxx14_standard
  • cxx17_standard
  • etc...

I've got an initial implementation of this capability that currently works on linux & macos, and does not break backwards compatibility:
#16552

I'd like to get some feedback from the Bazel team on if it's possible to get this merged before doing whatever else is necessary to meet the contribution requirements (design docs, testing, etc...).

What underlying problem are you trying to solve with this feature?

The original issue I was trying to solve was to get some code to build with bazel that mixes C/C++ code in the same target:

cc_library(
    name = "example",
    srcs = [
        "src/foo.cpp", # requires compiling with C++14
        "src/bar.c"
    ],
    copts = [
        "-Werror",
        "-std=c++14",
    ]
)

It's currently not possible to build that target with Bazel. This is because there's no way to distinguish between C and C++ flags at the cc_* rules level. The compiler will issue a warning when -std=c++14 is passed while compiling the C file, and -Werror will cause that warning to be propagated as a build error.

There are various alternatives but none of them are desirable:

  • Using BAZEL_CXXOPTS: Not able to control the standard at the target level, no equivalent for setting the C standard
  • Using --cxxopts/--copts at the command line: Also doesn't allow setting at the target level.
  • Splitting the code up into mutliple targets (one for the C portions, and one for the C++ portions). The build system should be flexible/powerful enough for developers to decide how they would like to structure their build/targets.
  • Writing a custom toolchain that implements the desired feature - Writing a custom toolchain is a big commitment with many other implications.

I think that the most elegant solution to this problem is to just expose a new set of features in the default toolchain that allow setting the standard. The features API enables distinguishing between C/C++ actions and avoids the scope issues above. Every target can mix and match C/C++ and decide the standard for each.

The POC branch I've linked shows that it should be possible to do this without breaking backwards compatibility of existing behavior, assuming that the order of flags is not part of the API.

Which operating system are you running Bazel on?

Windows, Linux, and Mac

What is the output of bazel info release?

5.3.2

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

Lots of research, still prefer my suggestion above.

Any other information, logs, or outputs that you want to share?

No response

@oquenchil oquenchil added P3 We're not considering working on this, but happy to review a PR. (No assignee) and removed untriaged labels Oct 26, 2022
@jungleraptor
Copy link
Contributor Author

@oquenchil Sorry don't know who else to ping. Any objections to this feature? Happy to do the remaining work if it can be accepted.

My initial PR that implements this feature is here: #16552

@Mizux
Copy link

Mizux commented Mar 31, 2023

My 2 cents,

  1. for C "only" you can use --conlyopt=... or --action_env=BAZEL_CONLYOPTS=..
    ed: copt was a wrong naming i.e. closer to CPPFLAGS (C PreProcessor) behaviour aka injected for C and C++ rules

ref:

conly_opts = split_escaped(get_env_var(
repository_ctx,
"BAZEL_CONLYOPTS",
"",
False,
), ":")
cxx_opts = split_escaped(get_env_var(
repository_ctx,
"BAZEL_CXXOPTS",
"-std=c++0x",
False,
), ":")

EDIT: b272cef only in preview 7
ref: https://www.gnu.org/software/make/manual/make.html#Implicit-Variables

  1. Adding c++ dialect in rules using copt in BUILD/WORKSPACE is against abseil-cpp policy
    ref: https://github.com/abseil/abseil-cpp/blob/master/FAQ.md#how-to-i-set-the-c-dialect-used-to-build-abseil

@fmeum
Copy link
Collaborator

fmeum commented Mar 31, 2023

At least for cc_* targets in external repositories, https://docs.google.com/document/u/1/d/132vEDnQZY0PtF9ko6HoLQ2dqk6meZnSrUfc1gsKuBkk/edit#heading=h.5mcn15i0e1ch could solve this as well.

@junyer
Copy link

junyer commented Jun 30, 2023

RTYI, @jsharpe. :)

Copy link

github-actions bot commented Sep 3, 2024

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs. If you think this issue is still relevant and should stay open, please post any comment here and the issue will no longer be marked as stale.

@github-actions github-actions bot added the stale Issues or PRs that are stale (no activity for 30 days) label Sep 3, 2024
@phst
Copy link
Contributor

phst commented Sep 3, 2024

I think this is still relevant.

@github-actions github-actions bot removed the stale Issues or PRs that are stale (no activity for 30 days) label Sep 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) team-Rules-CPP Issues for C++ rules type: feature request
Projects
None yet
Development

No branches or pull requests

7 participants