CMake Arm build errors

[austinbhale]

Hi! I'm following the guide for building StereoKit with CMake: https://github.com/StereoKit/SKTemplate-CMake#command-line-instructions.

I've been able to build for x64 and arm64, but arm is giving me two unresolved symbols.

I modified the commands to be like so:

# Configure the build:
cmake -G "Visual Studio 17 2022" -A ARM .. -DCMAKE_BUILD_TYPE=Debug
# Build
cmake --build . -j8 --config Debug --clean-first

And my CMakeLists.txt:

# To use this template, 
cmake_minimum_required(VERSION 3.11)
project(TestAPI_C VERSION "0.1.0" LANGUAGES CXX C)

# Grab and build StereoKit from the GitHub repository. Here we're setting SK up
# as a statically linked library.
include(FetchContent)
set(SK_BUILD_TESTS       OFF CACHE INTERNAL "")
set(SK_BUILD_SHARED_LIBS OFF CACHE INTERNAL "")
FetchContent_Declare(
  StereoKitC
  GIT_REPOSITORY https://github.com/StereoKit/StereoKit.git
  GIT_TAG        21c1db08db9d702db84d1bf8eea9e6f5658c2a1d # 0.3.7-preview.5
)
FetchContent_MakeAvailable(StereoKitC)

# Add source files to our target executable
add_library( TestAPI_C SHARED
 src/test.h
 src/test1.h
 src/test.cpp
)

# Link to dependencies
target_link_libraries( TestAPI_C
  PRIVATE StereoKitC
)

The error output:

StereoKitC.lib(file_picker.obj) : error LNK2019: unresolved external symbol __imp_GetOpenFileNameW referenced in functi
on platform_file_picker_sz [...\build_arm\NakamirAPI_C.vcxproj]
StereoKitC.lib(file_picker.obj) : error LNK2019: unresolved external symbol __imp_GetSaveFileNameW referenced in functi
on platform_file_picker_sz [...\build_arm\NakamirAPI_C.vcxproj]
...\build_arm\Debug\NakamirAPI_C.dll : fatal error LNK1120: 2 unresolved
externals [...\build_arm\NakamirAPI_C.vcxproj]

Is there anything I can do to bypass these errors? It's nice that the GIT_TAG can reference any commit if you know of one that would build successfully. Thanks!

[maluoi]

You're right, seems pretty specific to ARM! That's bizarre!

I added an explicit link to the missing .lib, and it seems to work now. I also bumped into some shader related stuff on /develop, and fixed that as well. Should be available in 8f49c7f.

Also, not sure if you're targeting Win32 or UWP, but the binaries are different, and those build instructions are for Win32! A UWP build would look like this:

cmake -G "Visual Studio 17 2022" -A x64 .. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_SYSTEM_NAME=WindowsStore -DCMAKE_SYSTEM_VERSION=10.0

I think there's still a few things I haven't done related to UWP and the cmake, but I don't think there's any hard blockers? (the test project doesn't get a necessary define, for example) If you are actually going the UWP route and encounter more troubles here, let me know!

[austinbhale]

It builds great now, thanks for adding those changes! Also, I am going the UWP route!

To expand a bit further on this CMake project, I've been experiencing one blocker today. Is there any way to reference the .vcxproj files from a .vsproj (e.g., a StereoKit UWP app) in the same solution?

For example, take the solution generated from the CMake (with reactphysics3d, StereoKitC, openxr, ...). Would you be able to reference this, or just the TestAPI_C or StereoKitC project from a C# UWP project? When doing so, I receive the following:

I've tried:

1. Adding the DLL (Right-click project > Add > Existing Item) as a link in the References. Result => Dll loads but it's missing dependencies
2. Looking into your StereoKitTest_UWP project file. How were you able to add StereoKitC_UWP as a reference?
3. Looking into NuGet package creation for native code. Not sure this is ideal since it'd be nice to have the code exposed in the same solution.

Program.cs

using StereoKit;
using System;
using System.Runtime.InteropServices;

namespace StereoKitProject1
{
    internal class Program
    {
        static void Main(string[] args)
        {
            // Initialize StereoKit
            SKSettings settings = new SKSettings
            {
                appName = "StereoKitProject1",
                assetsFolder = "Assets",
            };
            if (!SK.Initialize(settings))
                Environment.Exit(1);

            // Create assets used by the app
            Pose cubePose = new Pose(0, 0, -0.5f, Quat.Identity);
            Model cube = Model.FromMesh(
                Mesh.GenerateRoundedCube(Vec3.One * 0.1f, 0.02f),
                Default.MaterialUI);

            Matrix floorTransform = Matrix.TS(0, -1.5f, 0, new Vec3(30, 0.1f, 30));
            Material floorMaterial = new Material(Shader.FromFile("floor.hlsl"));
            floorMaterial.Transparency = Transparency.Blend;


            // Core application loop
            while (SK.Step(() =>
            {
                if (SK.System.displayType == Display.Opaque)
                    Default.MeshCube.Draw(floorMaterial, floorTransform);

                UI.Handle("Cube", ref cubePose, cube.Bounds);
                cube.Draw(cubePose.ToMatrix());

                System.Diagnostics.Debug.Write($"yo: ${API.hello()}");

            })) ;
            SK.Shutdown();
        }
    }

    public static class API
    {
        const string dll = "TestAPI_C";
        const CharSet cSet = CharSet.Ansi;
        const CallingConvention call = CallingConvention.Cdecl;

        [DllImport(dll, CharSet = cSet, CallingConvention = call)]
        public static extern int hello();
    }
}

Native header file

#include <stereokit.h>
...
extern "C" __declspec(dllexport) int hello() { return 1; }
...

I'm trying to follow in your path with NativeAPI in how you avoided writing a Windows Runtime Component through P/Invoke with the DLL.

[maluoi]

Oh, I think I see what you're doing now! This is basically a native plugin for a C# StereoKit app, very cool! I haven't tried this yet, but I'm very interested in how it goes.

One thing I'd recommend then is setting SK_BUILD_SHARED_LIBS to ON, that way the plugin DLL doesn't also contain a duplicate StereoKitC static linked into it!

I think what I'd recommend after that is compiling the plugin via command line calls in the Build Events of your main project, and then either directly referencing the compiled binaries, or copying the binaries into the output folder of the executable? I have historically found referencing binaries to be particularly tricky in UWP projects.

You might alternatively be able to reference the specific TestAPI_C .vcxproj of the built cmake project instead, this is what I do in StereoKitC_UWP! I believe this was added by the VS Add->Reference interface, but I also remember this being really fiddly, it may potentially have been added by hand. You can also add an external project to a Solution as well, which might help accelerate iteration?

<ProjectReference Include="..\..\..\StereoKitC\StereoKitC_UWP\StereoKitC_UWP.vcxproj">
  <Project>{45af7827-11ca-4691-a063-8c78fb0be1ec}</Project>
  <Name>StereoKitC_UWP</Name>
</ProjectReference>

[austinbhale]

Quick semi-related follow up:
For C projects referencing the StereoKitC project as a static library, do you think it'd be possible to have either another 1) VS project or 2) StereoKitC configuration, that would both have the ConfigurationType as a static library with a separate path? Or do you recommend using a build tool like cmake instead as a prebuild event?

[maluoi]

I'm not quite sure I followed this super well! Do you think you could explain a little more?

[austinbhale]

Sure thing! I'm referencing this static library selection aka https://github.com/StereoKit/StereoKit/blob/develop/StereoKitC/StereoKitC.vcxproj#LL31

I'd like to build StereoKitC as a static library so that I can reference it from a separate Visual Studio C project (without cmake). Unfortunately there doesn't seem to be a nice way to build both the DLL and static lib together in Visual Studio. For example, as talked about in this ancient thread => https://stackoverflow.com/questions/376296/building-both-dll-and-static-libs-from-the-same-project

The consensus I've seen is to either:

1. different configurations in addition to DEBUG/RELEASE, there could be a DEBUG_LIB/RELEASE_LIB that builds a static lib. then you could use msbuild to target the project and its configuration from the commandline
2. different projects where one is the DLL (like StereoKitC) and the other a static lib (StereoKitC_LIB). This would be nice for referencing, but I wish you could have a near-identical .vcxproj for StereoKitC with the small change of building for a static library. This could be achieved with a conditional compilation symbol or similar
3. just use a cmake project instead and avoid VS weirdness

[maluoi]

I've generally been kinda frustrated with Visual Studio's build tools, particularly for native! It has been a rather painful process. You can actually see a number of points where I have totally given up and just used build events to invoke xmake commands, particularly with respect to Android! (not to mention, building a small custom package manager)

I've also been considering moving the whole project over to cmake as well? As I start thinking about building via GitHub Actions, keeping Visual Studio involved in the process becomes less and less appealing. The VS project is already really fragile feeling. I still have a lot of investigation to go before I commit to that, but I've seen C# projects being done via cmake as well, so it may not be so farfetched to keep all SK's projects in the same cmake file! Visual Studio also supports opening cmake projects too, so I wouldn't need to give that up at all either.

I guess I'd say don't feel bad about using build events? I don't think they're a bad idea at all. Or honestly even cmake straight up. There's a few things small you can add to your cmake files to make them a little more palatable when you open them in Visual Studio too, like the source groups here.

I dunno, hopefully that's a little helpful!

[austinbhale]

Ahh I've wondered if you tried the VS way before xmake/cmake commands, glad to know it's a universal pain 🙃

I think the configs you could make with cmake for automated builds will offer way more flexibility for testing. The source groups detail is really neat! Never heard of those but wayy better than a jumbled pile of files. For the time being, I think I'll take your advice with the cmake prebuild event.

Also just played around with opening StereoKit's CMakeLists in VS and I dig the switching between cmake and .sln views. Some startup projects aren't working on my machine but unsure if that's because they aren't configured yet or my machine (edit: nvm they were the C# ones lol). It seems switching to the .sln view is necessary right now for deploying and changing .vsproj settings like retargeting, etc

Thanks for the tips!