Skip -march guessing for external cross toolchains

[leon-anavi]

Description

Don't add -march flag when CC/CROSS_COMPILE names an external cross toolchain (Yocto/OpenEmbedded, Buildroot, ...). These already inject the correct target. Avoid issues such as an unknown value 'x86-64-v2' for '-march' when cross compiling for ARM machine.

---

Related Issue(s)

Closes or relates to #

---

Checklist

• I have referenced relevant issue numbers above
• I have performed a self-review of my code and it follows
  the style guidelines of this project
• I have added new or used existing tests that prove my fix
  is effective or that my feature works
• I have added necessary documentation (if appropriate) and
  updated the changelog
• I have added an AI assistance disclosure file (required!)
  in this PR

---

AI Assistance Disclosure File

⚠️ Required for this PR: You MUST include a disclosure
file at .audit/<branch-name>.md right in this PR. The
disclosure file must follow the exact format and content as
described below. Your PR will not be accepted without a
disclosure file.

Example 1 file contents of your disclosure file
.audit/<branch-name>.md:

## AI Assistance Disclosure

- [ ] I did **not** use any AI-assistance tools to help create this pull request.
- [x] I **did** use AI-assistance tools to *help* create this pull request.
- [x] I have read, understood and followed the projects' [AI Policy](https://github.com/crossbario/autobahn-python/blob/main/AI_POLICY.md) when creating code, documentation etc. for this pull request.

Submitted by: @your-github-username
Date: YYYY-MM-DD
Related issue(s): #issue-number
Branch: branch-name

OR

Example 2 file contents of your disclosure file
.audit/<branch-name>.md:

## AI Assistance Disclosure

- [x] I did **not** use any AI-assistance tools to help create this pull request.
- [ ] I **did** use AI-assistance tools to *help* create this pull request.
- [x] I have read, understood and followed the projects' [AI Policy](https://github.com/crossbario/autobahn-python/blob/main/AI_POLICY.md) when creating code, documentation etc. for this pull request.

Submitted by: @your-github-username
Date: YYYY-MM-DD
Related issue(s): #issue-number
Branch: branch-name

---

Submitting code generated primarily by AI, or for which you
cannot claim human authorship, is not permitted. See
AI Policy
for details.

Example 1 OR Example 2 show the only valid two variants. You
cannot have both or none of the first two marks checked, and you
must always have the last tick checked.

Well, "must" if you want your PR to be accepted and ultimately
merged that is. Of course you are always free to
Go ahead! Fork my Day. (TM) ;) This is Open-source.

[oberstet]

Thanks for this! To be clear up front: the problem you hit is real, and the direction you took (don't second-guess an externally managed cross toolchain, which already injects its own -march/-mtune/-mcpu) is one I agree with.

I'm closing this PR, but not because the report (implied in the PR) is wrong — because reviewing it showed we can't yet say what it fixes. Let me explain, since I'd very much like to see this land properly eventually.

On the referenced issue. The audit file references #1930, which is the 26.7.1 release issue — already closed, and not a report of this problem. Our policy is that every change starts from an open issue describing the behaviour we consider wrong, so there's something concrete to agree on before code is written. (We're currently tightening this: the audit-file format and the open-issue requirement will be enforced in CI, and the contribution guide is being standardized across the WAMP Python projects. Our fault that this wasn't clearer — the guidance is genuinely inconsistent across our repos right now.)

On what we actually promise. Reviewing this raised a question I couldn't answer: Does autobahn promise anything about cross-compilation? It turns out the only statements are in a changelog entry and a docstring in src/autobahn/nvx/_compile_args.py — the latter claiming cross-compilation "works out of the box", with no CI job that cross-compiles anything behind it. That's an aspiration published as documentation, and it makes it impossible to tell whether a change like yours fixes a deviation from promised behaviour or introduces new behaviour.

So we've filed #1935 to write the promise down properly — in README.md and docs/installation.rst, with explicit support-status tags, and with a real cross-build CI target (riscv64 via Buildroot, cross-built on x86-64) to back it. Companion issues exist for zlmdb (crossbario/zlmdb#145) and Crossbar.io (crossbario/crossbar#2280).

How we'd want the fix to land, once the promise exists — we follow a two-phase test-driven workflow:

1. a test that demonstrates the bug, pushed first, and shown failing in CI (the "red" phase, documented in a PR comment linking the failing job);
2. the fix, making that same test pass in CI (the "green" phase, likewise documented).

That way the PR proves both that the behaviour was wrong and that it's now right, and the test stays in the suite so we don't regress. test_compile_args.py is the natural home for the unit-level part. As a real-world example, you can look at #1922 and the comments there.

One thing that would really help, and which only you can provide. I don't think the root cause is where this patch sits. If you got -march=x86-64-v2 while targeting ARM, that means sysconfig.get_platform() returned the host (linux-x86_64) in your build — but that function is precisely the mechanism we rely on to detect the target. So the guarantee broke one layer below where this patch applies, and the same detection failure would affect anything else deriving the target from sysconfig.

Could you open an issue with:

• the output of python3 -c "import sysconfig; print(sysconfig.get_platform())" in your build environment;
• whether your recipe exports _PYTHON_SYSCONFIGDATA_NAME (Buildroot sets this so sysconfig reports the target; if OE isn't setting it in your setup, that would explain the whole thing);
• the CC / CROSS_COMPILE values in effect.

There's also a design question your patch answers implicitly and which we should settle explicitly: what is authoritative about the target architecture — AUTOBAHN_ARCH_TARGET > a cross-toolchain signal (CC/CROSS_COMPILE) >
sysconfig? That's recorded in #1935, and your input on it would be welcome given you're closer to the Yocto/OE side than we are.

Two smaller notes on the patch itself, for whenever it's revived:

• if "-" in exe also matches common native compilers — gcc-13, clang-18, Debian's x86_64-linux-gnu-gcc — so those builds would silently lose the -march=x86-64-v2 baseline with no warning. It also misses wrapped cross
  toolchains like CC="ccache aarch64-poky-linux-gcc".
• The check sits before the safe/default branch, so an explicit AUTOBAHN_ARCH_TARGET=safe would be silently overridden by autodetection. Explicit user intent should win.

Thanks again for taking the time — this genuinely improved things on our side, just not in the shape of a merge. If you'd like to pick it back up after #1935 lands, that would be very welcome.