finitereality / finite.cpp.sdk Goto Github PK

Two-way bindings without much hassle should be possible, eventually. I think this will likely take the form of a separate package reference to extend the build based on which SDK is being used.

For sharing types between managed and unmanaged, there are multiple routes that would likely need to be taken:

• Generate C# types and methods from existing C/C++ code (a la ClangSharp - https://github.com/Microsoft/ClangSharp) when referencing a C/C++ library from C#
• Generate C/C++ types and methods from the C# types, failing if the types are not blittable (a la DNNE) when referencing a C# library from C/C++

Some examples of the desired XML:

<Project Sdk="Finite.Cpp.Sdk">
  <ItemGroup>
    <PackageReference Include="Finite.Cpp.Sdk.DotNetExports" />
  </ItemGroup>
  <ItemGroup>
    <ProjectReference Include="path/to/project.csproj" GenerateExports="true" />
  </ItemGroup>
</Project>

<Project Sdk="Microsoft.NET.Sdk">
  <ItemGroup>
    <PackageReference Include="Finite.Cpp.Sdk.NativeExports" />
  </ItemGroup>
  <ItemGroup>
    <ProjectReference Include="path/to/project.cxxproj" GenerateExports="true" />
  </ItemGroup>
</Project>

What file extensions do we want for C/C++ projects?

• vcxproj might be compatible with existing systems, but will likely blow everything else up. MSFT might also not be happy that we stole their extension
• cproj and cxxproj are incompatible with everything current, but this guarantees we aren't stepping on anybody's feet
• However, we could just use a single project type for both C/C++...

Because this would be totally useless without this! :)

Overall idea so far is to separate compile and link into separate steps to allow incremental builds. Tasks under src/Tasks/ roughly follow this.

Open questions:

• How do we expose compiler options to the user?
  • NativeCXX.targets mockup from Thermite has very platform-dependent options
  • But if we expose platform-independent options (e.g. <StandardVersion>c++17</StandardVersion> we'd need some database mapping these options)
• Reproducible/deterministic builds? (Super stretch goal)
• How do we want to use "standard" MSBuild properties?
• How do we reflect these in #2 for packaging?

Right now it's just set to $ORIGIN, which works in a lot of cases, but probably won't work in all cases (e.g. dynamically loaded plugins)

We'll need to write a CPS... something or other for this. I'm not the most familiar with Visual Studio internals, so my efforts until now have mostly been focused on the .NET and MSBuild command line.

This is an absolute must because it makes MSBuild in .NET Core so much nicer to work with.

https://github.com/microsoft/msbuild/blob/master/documentation/ProjectReference-Protocol.md

Assuming this is up to date, we could reference it while implementing ProjectReference support for our own projects. We should be careful to not trip up everything else though.

Goal is to have something comparable to CMake, so the information we need to detect is:

• Path
• Version
• Supported architecture(s)
• Supported features/standards (C++17, C99, GNU C, etc.)
• Whether the compiler works (compile a test program)
• Word size/similar (can be done using above test program)

How do we want to do packages? There are three options I see:

• NuGet (would this require NuGet to support us? I can't figure out how their MSBuild machinery works)
  • how do we redistribute code? Source form or glorified LLVM IR?
  • Licensing is fairly simple thanks to NuGet's built in support
• Vcpkg (integrates natively with MSBuild, so might be easy)
  • Everything's in a monorepo distributed by source
  • Licensing is ????
• A whole new system from the ground up because Not Implemented Here:tm: