armandomontanez

If the Bazel checks are getting in your way, you can add the two new files to a `filegroup` (which will silence the error) and file an issue+leave a TODO...

Backing up a bit to the most likely culprit just to double check: have you passed `-no-canonical-prefixes` (gcc/clang) and `-fno-canonical-system-headers` (gcc only) as compile flags in your toolchain, also making...

Separately, I need to stare at this change longer to determine whether or not it's correct but at first glance I *think* it is. Before landing this, I'd like to...

Related: https://github.com/bazelbuild/bazel/issues/4605

I've spent a bit of time unpacking this, and this looks like an interesting case where: * `-no-canonical-prefixes` is NOT in use. * `-isystempath/to/toolchain/foo/include` is manually passed to the toolchain....

FWIW, if you bump pip-tools to >7.5.0 the absolute path issue should be resolved when using pip >24.3. Issue: https://github.com/jazzband/pip-tools/issues/2131 Fix: https://github.com/jazzband/pip-tools/pull/2195

This also happens if you transition directly to `@platforms//host` rather than the indirection `@bazel_tools//tools:host_platform`.

Perhaps there's an argument to be made that we should just jump ship entirely on this expression, and use the names available for `-mcpu`. They're more granular, and better express...

It looks like @aiuto already clarified that we _should_ be using the CPU type itself (rather than ISA) moving forward: https://github.com/bazelbuild/platforms/commit/0f056b51eeae683a144b2d1fc64a10819212172d For now, I think the answer is to pivot...

I'm debating the value of converting the old variants to `alias` rules. Some translate trivially: `armv7-m`->`cortex-m3`, others less so: `armv7e-m`->[`cortex-m4` or `cortex-m7`]. Also `armv8-m` should probably map to Cortex-M33 since...