meson
meson copied to clipboard
Add compiler detection for Intel oneAPI DPC++/C++ Compiler.
Reported-by: Marcus Seyfarth [email protected] Suggested-by: Harry van Haaren [email protected] Tested-by: Vinson Lee [email protected] Tested-by: Marcus Seyfarth [email protected] Signed-off-by: Vinson Lee [email protected]
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 67.80%. Comparing base (
acef5a9) to head (d436118). Report is 2744 commits behind head on master.
Additional details and impacted files
@@ Coverage Diff @@
## master #9850 +/- ##
==========================================
- Coverage 67.80% 67.80% -0.01%
==========================================
Files 400 400
Lines 85522 85522
Branches 18825 18825
==========================================
- Hits 57987 57986 -1
- Misses 23035 23036 +1
Partials 4500 4500
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Just a note that this PR is the output of the longer discussion on issue https://github.com/mesonbuild/meson/issues/8113, and the code-change workings is described in https://github.com/mesonbuild/meson/issues/8113#issuecomment-961945940.
Merging this PR will enable Meson to correctly detect and use the OneAPI compiler.
As this is new functionality it should have a release note snippet.
Isn't this going to result in using th eIntel compiler with an Id as clang? Even if it uses clang under the hood, there are still some differences right, enough to justify having at least a unique name like "oneAPI" or "Intel DPC" or something (just not intel or intel-cl)?
I think a new ID is called for (CMake gives it IntelLLVM, but oneapi or intel-oneapi is probably fine). As a concrete use case, the Intel OneAPI compiler has some…interesting decisions around some flag defaults that projects probably want to be able to detect it specifically (of note, -fp-model=precise is needed to remove -ffast-math-like behaviors on -O1 and above).
That's... interesting. And means that the implementation in Meson needs to override the optimization levels as well, so that we add -fp-mode=precise to the arguments by default
I think a new ID is called for (CMake gives it
IntelLLVM,
This is what gh-10909 does. So that probably supercedes this PR.
It adds a new class, but doesn't override anything such as the ID.
It is the right approach, just not all the way there. :)
Just noting that this hasn't been touched in 2 years, and it'd be really nice to have!
@aaronsuydam #10909 implements this, and has been landed for almost 2 years. The only think I see here that we don't have upstream is the note about the -fp-model=precise. Since the intention of this is already upstream, I'm going to close this.
@dcbaker ah ok great. There's nothing in the web docs about this having been implemented (that I saw), what's the meson.build option I need to use? Haven't been able to get it to work.
@aaronsuydam there isn't a meson.build option. It is supporting a new compiler and compilers are defined in the toolchain ("machine") file or inferred by setting the environment variables CC and CXX.
The meson docs include a reference table listing supported compilers alongside the ID return values for checking inside meson.build "which compiler is this build directory + toolchain configured to use".
intel-llvm --> Intel oneAPI LLVM-based compiler
It's also mentioned in the release notes for meson 0.64.0