You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While working on #1230, it came to my attention that if CPPFLAGS is included in the env of a configure_make rule, they are also ignored. I think this should be supported like the other xxxFLAGS variables and would like to get feedback on a PR that touches the code as follows:
I would also like to clean up the names of the variables inside CxxFlagsInfo since they are quite misleading and inconsistent. Linked flags are language in dependent. Would the following be acceptable? I think this provider is just used internally so it would not be a breaking change, right?
CFlagsInfo=provider(
doc="Flags for the C/C++ tools, taken from the toolchain",
fields=dict(
c="C compiler flags",
cxx="C++ compiler flags",
cpp="C/C++ preprocessor flags",
linker_shared="Linker flags when linking shared library",
linker_static="Linker flags when linking static library",
linker_executable="Linker flags when linking executable",
asm="Assembler flags",
),
)
The text was updated successfully, but these errors were encountered:
While working on #1230, it came to my attention that if
CPPFLAGS
is included in theenv
of aconfigure_make
rule, they are also ignored. I think this should be supported like the otherxxxFLAGS
variables and would like to get feedback on a PR that touches the code as follows:Add
CPPFLAGS
to_MAKE_FLAGS
:https://github.com/bazelbuild/rules_foreign_cc/blob/9d5727d5e51bf1be8423dff7996bdb4d847b47e6/foreign_cc/private/make_env_vars.bzl#L79-L88
Add
cpp
toCxxFlagsInfo
provider struct:https://github.com/bazelbuild/rules_foreign_cc/blob/9d5727d5e51bf1be8423dff7996bdb4d847b47e6/foreign_cc/private/cc_toolchain_util.bzl#L28-L38
I would also like to clean up the names of the variables inside
CxxFlagsInfo
since they are quite misleading and inconsistent. Linked flags are language in dependent. Would the following be acceptable? I think this provider is just used internally so it would not be a breaking change, right?The text was updated successfully, but these errors were encountered: