Add tools.build:asmflags consumed by CMakeToolchain (CMAKE_ASM_FLAGS)

[szostaba]

Today CMakeToolchain sets C/CXX/shared-link/exe-link/RC flags and defines, but nothing populates CMAKE_ASM_FLAGS. Projects with hand-written assembly (e.g. MCU startup .s files) currently have to mirror tools.build:cflags onto CMAKE_ASM_FLAGS by hand in their recipe. This closes that gap by mirroring the existing tools.build:cflags/cxxflags handling for assembly:

• new tools.build:asmflags conf (registered in BUILT_IN_CONFS),
• new CMakeToolchain.extra_asmflags attribute, for parity with extra_cflags/extra_cxxflags,
• ExtraFlagsBlock emits CONAN_ASM_FLAGS; CMakeFlagsInitBlock maps it to CMAKE_ASM_FLAGS_INIT (both the global and the per-config variants),
• integration tests covering both the conf and the attribute path.

Scope: CMakeToolchain only — the conf docstring is intentionally CMake-only. Possible follow-ups: AutotoolsToolchain/GnuToolchain parity via the existing ASFLAGS hook (their asflags property is currently Apple-only and would need the if not is_apple_os: return [] guard reworked so flags aren't dropped elsewhere). Meson is out of scope — its generated machine file has no assembly-args slot.

Changelog: Feature: Add tools.build:asmflags config and CMakeToolchain.extra_asmflags to populate CMAKE_ASM_FLAGS.
Docs: Omit

• Refer to the issue that supports this Pull Request.
• If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
• I've read the Contributing guide.
• I've followed the PEP8 style guides for Python code.
• I've opened another PR in the Conan docs repo to the develop branch, documenting this one.

[CLAassistant]

All committers have signed the CLA.

[memsharded]

Hi @szostaba

Thanks for your contribution.

There was already a PR opened for this in #17237.
But that PR had some open questions like:

• dialects
• What happens with other build systems
• Risks of breaking?

See the last comment in that PR #17237 (comment)

[szostaba]

Hi @memsharded,

thanks — I've read #17237 and @jwidauer's thread. Addressing the three open questions directly.

1. Dialects

tools.build:asmflags maps to CMAKE_ASM_FLAGS_INIT — only the generic CMake ASM language (enable_language(ASM), assembled via the C compiler / GNU as). It deliberately does not touch the other dialects (ASM_NASM, ASM_MASM, ASM_MARMASM, ASM-ATT), which each have their own CMAKE_<dialect>_FLAGS.

That's intentional: each dialect is a different assembler with incompatible flag syntax (-mcpu=... -Wa,... means nothing to nasm/masm; /Cp or -f elf64 mean nothing to gcc), so one shared value can't sensibly fan out to all of them. Mapping to CMAKE_ASM_FLAGS is the only coherent option — same as tools.build:rcflags → the single CMAKE_RC_FLAGS. I'll state this scope explicitly in the docstring.

2. Other build systems

CMakeToolchain-only, on purpose. The conf name is build-system-agnostic, so it can be extended later, but I'm not claiming unimplemented support. Precedent: tools.build:rcflags is consumed by CMake/MSBuild/Meson but not Autotools — partial coverage is fine if the docstring is honest.

Feasibility: Autotools/Gnu already emit an ASFLAGS env var, so a follow-up is doable (caveat: their asflags property is currently Apple-only — if not is_apple_os: return [] — and would need adjusting so flags aren't dropped elsewhere). Meson has no per-language assembly-args slot, so I'd leave it out. Happy to do the Autotools follow-up separately. The docstring will be marked (experimental) and CMakeToolchain-only, as agreed in #17237.

3. Risks of breaking

Fully opt-in: the CONAN_ASM_FLAGS / CMAKE_ASM_FLAGS_INIT lines are emitted only when tools.build:asmflags is set (guarded by {% if asmflags %}). With it unset, the generated conan_toolchain.cmake is byte-for-byte identical to today.

And nothing is auto-injected: Conan does not add arch_flag/sysroot/etc. to CONAN_ASM_FLAGS — it's exactly what the user provides, same contract as tools.build:cflags. So the "arch_flag breaks non-mainstream assemblers" scenario doesn't apply. I validated it end-to-end (CMake enable_language(ASM) + a real .s, gcc, the flag reaching the assembler via CMAKE_ASM_FLAGS_INIT) and will add a functional test under test/functional/toolchains/cmake/.

Use case (why not just cflags?)

You're right that with gcc as the assembler, cflags often covers .s/.S. But the missing conf forces a real workaround in practice. Our case: bare-metal ARM Cortex-M4F firmware with ThreadX (C + hand-written assembly), cross-compiled with both arm-none-eabi-gcc and arm-none-eabi clang. The arch/target flags (--target=arm-none-eabi, -mcpu=..., FPU) have to reach the assembler for the startup/context-switch .s to build, so every recipe with assembly currently mirrors cflags onto CMAKE_ASM_FLAGS by hand:

# Conan has no asm-flags conf, so mirror the C flags onto the assembler.
tc.cache_variables["CMAKE_ASM_FLAGS"] = " ".join(
    self.conf.get("tools.build:cflags", default=[], check_type=list))

And this is exactly where cflags ≠ asmflags: pushing the full C flag set onto the assembler makes clang emit unused-command-line-argument warnings (compile-only flags it ignores while assembling), which we then have to silence with -Wno-unused-command-line-argument in the profile. A dedicated tools.build:asmflags lets us pass only the assembler-relevant flags — removing both the per-recipe boilerplate and the need to suppress those warnings.

Why not extra_variables?

tools.cmake.cmaketoolchain:extra_variables works as an escape hatch but isn't equivalent: it renders set(CMAKE_ASM_FLAGS ...) (overwrites instead of composing through the _INIT hook like cflags/cxxflags), has no per-config handling, and forces raw CMake-variable plumbing for the one flag that isn't a first-class tools.build:*flags conf. The actual change is ~6 lines following the existing rcflags pattern.

Sourcing (profile conf vs cpp_info)

On your cpp_info.cxxflags point: like tools.build:rcflags, asmflags is profile-[conf] only — it isn't aggregated from dependencies' cpp_info model. Dependency-propagated asm flags could be a follow-up if there's demand, but the consumer-side conf already covers the case above.

---

Next steps if this is OK: (a) docstring → (experimental), generic ASM / CMakeToolchain only; (b) add the functional test; (c) optionally a follow-up for Autotools ASFLAGS. Happy to consolidate with #17237 / @jwidauer however you prefer.

[memsharded]

Merged, it will be in next Conan 2.31 release.
Many thanks for your contribution!