Skip to content

Replace name-based clang detection with CMAKE_CXX_COMPILER_ID - #9674

Merged
greglandrum merged 1 commit into
rdkit:masterfrom
barlowa124:clang-detection-9662
Oct 13, 2026
Merged

greglandrum merged 1 commit into
rdkit:masterfrom
barlowa124:clang-detection-9662

Conversation

@barlowa124

@barlowa124 barlowa124 commented Oct 5, 2026 •

Copy link
Copy Markdown
Contributor

Reference Issue

Fixes #9662 and resolves #9663.

What does this implement/fix? Explain your changes.

CMAKE_COMPILER_IS_CLANG was detected by matching clang inside the
CMAKE_C_COMPILER path, so a differently-named clang is missed
entirely. FreeBSD's base cc/c++ and the packaged clang/clang++
suffixed names both fall outside the match.
The BOOST_SYSTEM_NO_DEPRECATED site had a CMAKE_CXX_COMPILER_ID
fallback (the double-check #9663 asks about) but the bison warning
suppressions in SmilesParse/SLNParse tested the custom variable
alone and silently never applied.

All four sites now match CMAKE_CXX_COMPILER_ID MATCHES "Clang"
directly and the custom variable is deleted. CMake derives the ID by
running the compiler, so detection no longer depends on the executable
name, and the #9663 fallback becomes redundant. MATCHES "Clang" also
covers AppleClang. CMAKE_COMPILER_IS_EMCC is untouched.

Any other comments?

cmake .. reconfigures cleanly under AppleClang 17, exercising
the changed conditions. No CMAKE_COMPILER_IS_CLANG references
remain. The fix relies on CMake's compiler-ID detection rather than a
FreeBSD install. The cc --version output quoted in #9662 contains
the FreeBSD clang version string the check matches.

CMAKE_COMPILER_IS_CLANG was set by matching "clang" in the C compiler's
executable name, which misses clang installations named cc/c++ (e.g.
FreeBSD base) or versioned names like clang23 (rdkit#9662). The two bison
warning suppressions in SmilesParse/SLNParse used only this variable and
had no fallback, so they never applied under a differently-named clang.

CMAKE_CXX_COMPILER_ID is computed by running the compiler and matching
its version output, so it identifies clang under any executable name.
All use sites now test it directly and the custom variable is removed,
which also resolves rdkit#9663's question about the redundant double check.
@greptile-apps

greptile-apps Bot commented Oct 5, 2026 •

Copy link
Copy Markdown
Contributor

RetriggerConfidence Score: 5/5

[Medium risk] Build system compiler detection logic.

The PR appears safe to merge; no actionable regression was identified.

Summary

The PR replaces executable-name-based Clang detection with CMake’s C++ compiler ID for the Boost compatibility flags and generated-parser warning suppressions.

  • This covers Clang when its executable has a non-Clang name.
  • The Emscripten condition is retained.

Reviews (1) · Last reviewed commit: "Replace name-based clang detection with ..."

@greglandrum greglandrum left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

Thanks for the contribution @barlowa124

@greglandrum

Copy link
Copy Markdown
Member

@yurivict the changes here look good to me, but I don't have a FreeBSD system. Could you please take a look and see if these resolve the problems you were seeing?

@greglandrum
greglandrum merged commit 498a5e8 into rdkit:master Oct 13, 2026
14 checks passed
greglandrum pushed a commit that referenced this pull request Nov 5, 2026
CMAKE_COMPILER_IS_CLANG was set by matching "clang" in the C compiler's
executable name, which misses clang installations named cc/c++ (e.g.
FreeBSD base) or versioned names like clang23 (#9662). The two bison
warning suppressions in SmilesParse/SLNParse used only this variable and
had no fallback, so they never applied under a differently-named clang.

CMAKE_CXX_COMPILER_ID is computed by running the compiler and matching
its version output, so it identifies clang under any executable name.
All use sites now test it directly and the custom variable is removed,
which also resolves #9663's question about the redundant double check.

Co-authored-by: barlowa124 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

2 participants