Invalid preprocessor command 'include_next'

[Cameron]

Installed oneAPI 2025.0.0 and am getting this error on an IFX based build that contains several C/C++ projects in Visual Studio 2022:

error C1021: invalid preprocessor command 'include_next'

Visual Studio dumps me in float.h at "C:\Program Files (x86)\Intel\oneAPI\compiler\latest\opt\compiler\include\float.h" at the very bottom at line 450:

The files in question are in a C based project that is set to use MSVC, not Intel C/C++ compiler. Have I missed something obvious?

[Steve_Lionel]

1) You posted this in an Intel Fortran forum, not Intel C++.

2) That is an MSVC error message, I'm pretty sure.

[Cameron]

Apologies if this was the wrong place, but we primarily deal with ifort and ifx based Fortran builds so my mind was set on this forum. If it is possible, I am fine if this post is moved (or I can recreate if it's necessary to post in the C/C++ forum).

Our Visual Studio solutions contain a mixture of both Fortran and C/C++ projects. I only see this error after upgrading from oneAPI 2024.2.0 to oneAPI 2025.0.0 Base & HPC toolkits.

[Steve_Lionel]

I'd check to see which preprocessor symbols are defined for your compilation. Looking at the build log may help.

[Cameron · Accepted solution]

Posting the fix in case someone searches for this exact error since this post seems to come up now. I hate when I find the exact forum post that says "I fixed it" without saying how!

In our build environment, we use a Directory.Build.targets file that modifies what Visual Studio uses for the IncludePath and LibraryPath variables. At one point we needed to have a programmatic way to switch the version of the Fortran compiler used to build the product. Visual Studio will recursively try to find this file (similar with .props) on launch and then load the instructions within.

My .targets file specifically set IncludePath to insert oneAPI paths before the content of what already existed in IncludePath. This causes Visual Studio to load float.h from the Intel include files, not from the Windows SDK if using Visual C++ / MSVC. The simple fix for me was to just append oneAPI paths after IncludePath like so:

$(IncludePath);C:\Program Files (x86)\Intel\oneAPI\compiler\2025.0\opt\compiler\include; ... <other paths>

If there is a better way to set these paths, I would appreciate the feedback. Our automated builds run devenv from headless instances (like cmd.exe). Most of this behavior stems directly from our need to use IVF 12, IVF 15, IVF 19, and others at the same time for different products we supported. Modifying the VC++ properties manually was tedious, so our dev team moved to .targets that has conditionals on the version of VC that is launched to consume the file. Good news is that we no longer need the older IVF, we are purely oneAPI 2024.2.1 now and are migrating to IFX as quickly as we can.

[Steve_Lionel]

Do you know about the devenv option /useenv? This causes VS to use the current process' environment variables rather than what it would normally use. If you fully establish INCLUDE, LIB and PATH before invoking /useenv, you'll have full control over what gets used.