microsoft
Windows App SDK 1.7.3：`base.h` `#elif _DEBUG` gives build error C1017: invalid integer constant expression
Describe the bug
#define CPPWINRT_VERSION "2.0.250303.1"
#if !defined(__cpp_lib_source_location) || defined(WINRT_NO_SOURCE_LOCATION) // Case1: cpp17 mode. The source_location intrinsics are not available. // Case2: The caller has disabled source_location support. Ensure that there is no binary size overhead for line/file/function. #define WINRT_IMPL_BUILTIN_LINE 0 #define WINRT_IMPL_BUILTIN_FILE nullptr #define WINRT_IMPL_BUILTIN_FUNCTION nullptr #elif defined(_DEBUG) // cpp20 _DEBUG builds include function information, which has a heavy binary size impact, in addition to file/line. #define WINRT_IMPL_BUILTIN_LINE __builtin_LINE() #define WINRT_IMPL_BUILTIN_FILE __builtin_FILE() #define WINRT_IMPL_BUILTIN_FUNCTION __builtin_FUNCTION() #else // Release builds in cpp20 mode get file and line information but NOT function information. Function strings // quickly add up to a substantial binary size impact, especially when templates are heavily used. #define WINRT_IMPL_BUILTIN_LINE __builtin_LINE() #define WINRT_IMPL_BUILTIN_FILE __builtin_FILE() #define WINRT_IMPL_BUILTIN_FUNCTION nullptr #endif
Steps to reproduce the bug
_DEBUG is defined, but in a way that doesn't resolve to a valid integer constant expression:
Expected behavior
No response
Screenshots
No response
NuGet package version
Windows App SDK 1.7.3: 1.7.250606001
Packaging type
Unpackaged
Windows version
Windows 11 version 24H2 (22621, October 2024 Update)
IDE
No response
Additional context
No response
Also,
_DEBUG is defined, but in a way that doesn't resolve to a valid integer constant expression:
_DEBUG;%(PreprocessorDefinitions)
Anything in the Visual Studio Preprocessor Definitions options gets translated to the /D command line option for cl.exe. So as an example,
If you set Visual Studio to diagnostic output then you can find something like:
1> C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\bin\HostX64\x64\CL.exe /c /ZI /JMC /nologo /W3 /WX- /diagnostics:column /sdl /Od /D _DEBUG /D _CONSOLE /D _UNICODE /D UNICODE /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /std:c++17 /permissive- /Fo"x64\Debug\\" /Fd"x64\Debug\vc143.pdb" /external:W3 /Gd /TP /FC /errorReport:prompt main.cpp
1> Tracking command:
1> C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\amd64\Tracker.exe /d "C:\Program Files (x86)\MSBuild\15.0\FileTracker\FileTracker32.dll" /i C:\Users\Darran\source\repos\test\test\x64\Debug\test.tlog /r C:\USERS\DARRAN\SOURCE\REPOS\TEST\TEST\MAIN.CPP /b MSBuildConsole_CancelEventd5692eb26b7f4d5b9b73d3d3e6845515 /c "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\bin\HostX64\x64\CL.exe" /c /ZI /JMC /nologo /W3 /WX- /diagnostics:column /sdl /Od /D _DEBUG /D _CONSOLE /D _UNICODE /D UNICODE /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /std:c++17 /permissive- /Fo"x64\Debug\\" /Fd"x64\Debug\vc143.pdb" /external:W3 /Gd /TP /FC /errorReport:prompt main.cpp
1> main.cpp
in the output. If you look in the build intermediate directory, you can also find the <projectname>.tlog directory. This has the CL.command.1.tlog (the 1 should be its position in the build order). This contains the options given to the compiler on the command line. This contains something like:
^C:\USERS\DARRAN\SOURCE\REPOS\TEST\TEST\MAIN.CPP
/c /ZI /JMC /nologo /W3 /WX- /diagnostics:column /sdl /Od /D _DEBUG /D _CONSOLE /D _UNICODE /D UNICODE /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /std:c++17 /permissive- /Fo"X64\DEBUG\\" /Fd"X64\DEBUG\VC143.PDB" /external:W3 /Gd /TP /FC C:\USERS\DARRAN\SOURCE\REPOS\TEST\TEST\MAIN.CPP
The reason why I mention this is because of the documentation for the /D option.
"By default, the value associated with a symbol is 1. For example, /D name is equivalent to /D name=1. In the example at the end of this article, the definition of TEST is shown to print 1."
If you have code such as:
#include <cstdio>
int wmain()
{
wprintf(L"%d\n", _DEBUG);
return 0;
}
1 is indeed written to the console, so the preprocessor symbols have a valid integer value in your case.
Have you modified any preprocessor definitions? I have not had any problems building using this version of C++/WinRT with the compiler set to C++20. Yes, I am also aware that the abover command lines show /std:c++17, they were only to show that preprocessor directives are translated to /D.
@DarranRowe, thank you! Your explanation is very clear.
My project use the boost-python, and i found the file ..\boost\install\include\boost-1_87\boost\python\detail\wrap_python.hpp in line 209 redefine the macro _DEBUG
when i put mouse over _DEBUG macro , the tooltip does't display _DEBUG=1 (the code is modifed and use defined(_DEBUG) )
when i create new winui3 project with windowsappsdk 1.7.3 and put mouse over _DEBUG macro, tooltip display _DEBUG=1
My project build comandline is this:
to solve this problem, i prefer to use #elif defined(_DEBUG) in line 203.
As I previously wrote, the CppWinRT repository is here.
The Windows App SDK uses CppWinRT to generate the projection, and base.h is part of that. To demonstrate this, I set up a little command line environment. I download the CppWinRT package from NuGet, extract it (since it is a renamed .zip file) to a directory named cppwinrt.
The executable, cppwinrt.exe, can be found easily inside this directory.
I am using this since it is the version that the WinUI 3 project templates use. Anyway, if I use this to generate a projection for just the Windows Union metadata, no Windows App SDK at all, then base.h is still generated.
But I will also say that boost-python undefining and redefining preprocessor constants in a method not compatible with the original definition is a major problem too.