Remove unused pybind copts

[keith]

Since this target has no srcs these are unused

[junyer]

The config_setting is also used in build_defs.bzl, so it would need to be moved there, but... I rather suspect the copts will be used by the parse_headers feature, the --process_headers_in_dependencies flag et cetera? And it seems that they were necessary back in commit https://github.com/pybind/pybind11_bazel/commit/00b46036517aae8ac3541e9da5b35a73fd07e492, so I'm getting real Chesterton's fence vibes. What are your thoughts, @fmeum? :)

(Ping, @rwgk.)

[rwgk]

(Ping, @rwgk.)

Ack that I have seen this, but I don't think I know anything that might be helpful here.

[keith]

Ah yes parse_headers using these makes sense. I assume @fmeum is right and these flags are specific to Google, since they aren't valid AFAICT. If it's for parse_headers I suppose we could fix them to make that work with bazel's support instead

[junyer]

What if we yeet just the -Xclang-only and -Xgcc-only options – and keep only the -fexceptions option?

[keith]

sounds good, updated to that. Looks like using parse_headers fails in python headers either way right now (at least on macOS):

% bazel build ... --process_headers_in_dependencies --features=parse_headers
...

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
external/rules_python~~python~python_3_11_aarch64-apple-darwin/include/python3.11/bytesobject.h:27:1: error: unknown type name 'PyAPI_DATA'
PyAPI_DATA(PyTypeObject) PyBytes_Type;
^
external/rules_python~~python~python_3_11_aarch64-apple-darwin/include/python3.11/bytesobject.h:27:25: error: expected ';' after top level declarator
PyAPI_DATA(PyTypeObject) PyBytes_Type;
                        ^
                        ;
external/rules_python~~python~python_3_11_aarch64-apple-darwin/include/python3.11/bytesobject.h:28:1: error: unknown type name 'PyAPI_DATA'
PyAPI_DATA(PyTypeObject) PyBytesIter_Type;
^

[keith]

I think this one is good to go

[jiawen]

I think this one is good to go

I'll take a look at this when I get a few cycles (i.e., tomorrow) but might need some time to grok the issue.