Error building: CMAKE re

[Noemata]

I opted to use the CMAKE that comes with VS 2022, but I get this error:

cmake .\CMakeLists.txt -- Building for: Visual Studio 17 2022 -- Selecting Windows SDK version 10.0.26100.0 to target Windows 10.0.22631. -- The C compiler identification is MSVC 19.42.34433.0 CMake Error at C:/Program Files/Microsoft Visual Studio/2022/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.29/Modules/CMakeDetermineSwiftCompiler.cmake:52 (message): Swift language not supported by "Visual Studio 17 2022" generator Call Stack (most recent call first): CMakeLists.txt:3 (project)

-- Configuring incomplete, errors occurred!

It seemed like you were also using VS CMAKE. Any suggestions?

[Noemata]

Hadn't noticed your build instructions, sorry. I'm guessing the compiler being reported as "broken" is the problem. This was acquired from the Browser Company Swift installer. Now I'm getting this:

PS D:\Swift_with_WinUI\swiftwinrt> cmake --preset debug Preset CMake variables:

CMAKE_BUILD_TYPE="RelWithDebInfo" CMAKE_C_COMPILER="clang-cl"

-- The C compiler identification is Clang 19.1.3 with MSVC-like command-line -- The Swift compiler identification is Apple 6.1 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - failed -- Check for working C compiler: C:/Users/xxx/AppData/Local/Programs/Swift/Toolchains/0.0.0+Asserts/usr/bin/clang-cl.exe -- Check for working C compiler: C:/Users/xxx/AppData/Local/Programs/Swift/Toolchains/0.0.0+Asserts/usr/bin/clang-cl.exe - broken CMake Error at C:/Program Files/Microsoft Visual Studio/2022/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.29/Modules/CMakeTestCCompiler.cmake:67 (message): The C compiler

"C:/Users/xxx/AppData/Local/Programs/Swift/Toolchains/0.0.0+Asserts/usr/bin/clang-cl.exe"

is not able to compile a simple test program.

It fails with the following output:

Change Dir: 'D:/Swift_with_WinUI/SwiftWinRT/build/debug/CMakeFiles/CMakeScratch/TryCompile-dm84sv'

Run Build Command(s): C:/PROGRA~1/MIB055~1/2022/ENTERP~1/Common7/IDE/COMMON~1/MICROS~1/CMake/Ninja/ninja.exe -v cmTC_05799
[1/2] C:\Users\xxx\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\clang-cl.exe  /nologo   /DWIN32 /D_WINDOWS  /Zi /Ob0 /Od /RTC1 -MDd /showIncludes /FoCMakeFiles\cmTC_05799.dir\testCCompiler.c.obj /FdCMakeFiles\cmTC_05799.dir\ -c -- D:\Swift_with_WinUI\SwiftWinRT\build\debug\CMakeFiles\CMakeScratch\TryCompile-dm84sv\testCCompiler.c
[2/2] C:\WINDOWS\system32\cmd.exe /C "cd . && "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E vs_link_exe --intdir=CMakeFiles\cmTC_05799.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100261~1.0\x86\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100261~1.0\x86\mt.exe --manifests  -- C:\Users\xxx\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\lld-link.exe /nologo CMakeFiles\cmTC_05799.dir\testCCompiler.c.obj  /out:cmTC_05799.exe /implib:cmTC_05799.lib /pdb:cmTC_05799.pdb /version:0.0 /machine:x64  /debug /INCREMENTAL /subsystem:console  kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ."
FAILED: cmTC_05799.exe
C:\WINDOWS\system32\cmd.exe /C "cd . && "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E vs_link_exe --intdir=CMakeFiles\cmTC_05799.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100261~1.0\x86\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100261~1.0\x86\mt.exe --manifests  -- C:\Users\xxx\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\lld-link.exe /nologo CMakeFiles\cmTC_05799.dir\testCCompiler.c.obj  /out:cmTC_05799.exe /implib:cmTC_05799.lib /pdb:cmTC_05799.pdb /version:0.0 /machine:x64  /debug /INCREMENTAL /subsystem:console  kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ."
LINK Pass 1: command "C:\Users\xxx\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\lld-link.exe /nologo CMakeFiles\cmTC_05799.dir\testCCompiler.c.obj /out:cmTC_05799.exe /implib:cmTC_05799.lib /pdb:cmTC_05799.pdb /version:0.0 /machine:x64 /debug /INCREMENTAL /subsystem:console kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTFILE:CMakeFiles\cmTC_05799.dir/intermediate.manifest CMakeFiles\cmTC_05799.dir/manifest.res" failed (exit code 1) with the following output:
lld-link: error: <root>: undefined symbol: mainCRTStartup
ninja: build stopped: subcommand failed.

CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:3 (project)

[Noemata]

Never mind. Was able to get everything to build, though I did have some odd messages. FYI, the build instructions need a lot of tweaking.

[tristanlabelle]

You need to use the CMake presets and build from a Visual Studio Developer Command Prompt, as you've probably found! I'm a solo developer on this project and it has no users yet so instructions have not been a priority, but I'll take note to improve them

[tristanlabelle]

I just reviewed the instructions and found nothing missing. Can you help me understand what tweaking they need?

[Noemata]

No worries. You got me pretty far as is. So far I've been working with Swift on the Mac, even though most of my previous work has been with all the XAML dialects on Windows. There was no variation of using VS's CMAKE that worked for me, so I did some grumbling around that. CMAKE inside of VSCode seems to be a requirement, at least on the 4 variations of systems I tried building on. I'm sure the churn with Microsoft products doesn't help. How the nugget package gets employed wasn't obvious either. I'll see how far I get with this over the weekend. I've only been using VSCode for a couple days (exactly 2). Will write something more detailed once I see where this lands. Thank you very much for replying.

[tristanlabelle]

I believe VS' CMake is what I've been using locally but I might also have installed a newer version.

I'm not quite at the point of publishing the nuget package, but there's a script to build it and it can then be copied into the nuget/override directory in swift-winui-sample as TristanLabelle.SwiftWinRT.0.0.0.nupkg and will get used by the build (you might need to delete the nuget lockfile too). Again, this is all quite experimental.

[Noemata]

I'm most of the way there at this point. Commenting here just to thank you for your hints. Very helpful. In my new issue posted here I identified the problem with my setup. I hadn't noticed that my amd64 systems had that explicitly set as the platform, which broke the build. I'm also slightly ahead of your environment and had to make a couple other minor tweaks to get everything to build.

[tristanlabelle]

I'm also slightly ahead of your environment and had to make a couple other minor tweaks to get everything to build.

@Noemata , Could you list those minor tweaks out so I can improve things for others?

[Noemata]

Inside GenerateWinMD.cmake, the revised version of this line is as follows:

cmake_path(CONVERT "${WINSDK_REFERENCES_DIR}/Windows.Foundation.UniversalApiContract/19.0.0.0/Windows.Foundation.UniversalApiContract.winmd" TO_NATIVE_PATH_LIST UNIVERSALAPICONTRACT_WINMD_NATIVE)

I think you have "15.0.0.0". That was a surprise.

I launch a vanilla command prompt and execute this combo:

"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x64 Code

So VSCode inherits the correct platform setting. Otherwise, on two of my systems, the build fails. Sadly for me, that's where I was trying to get this going. Bad luck. Took forever for me to realize the issue.

[Noemata]

Might be a good idea to be more adaptive with the WinUI version being supported. Your design should work up version, if not down. So you likely have to check for a minimum supported version, but the build could select whatever is the latest, unless the user provides an override.

[tristanlabelle]

I think you have "15.0.0.0". That was a surprise.

That number would depend on the Windows SDK version. I can remove that assumption.

[tristanlabelle]

The project should be completely independent of the WinUI version. It's also independent of the Windows SDK version even though I might have let slip some constants like that 15.0.0.0 that are specific to what I have on my system.

[Noemata]

Again, no worries. It's a very minor issue. Was tripping me up because it caused a chunk of the build to fail. I have a better understanding of how things are put together and can help myself a bit more.