vezel-dev / zig-sdk Goto Github PK

The MinGW C/C++ headers included with Zig don't seem to work well for this target at all.

Also, __chkstk is missing when building Zig code.

https://github.com/ziglang/zig/milestone/17

We definitely need to pass -rpath '$ORIGIN'. We might also need to consider -rpath '$ORIGIN/runtimes/<rid>/native'.

For these to actually work properly, we also need to pass -soname libfoo.so for shared libraries.

Depends on: ziglang/zig#9222

It blocks win-x86 completely (see ziglang/zig#8531) and breaks various other platform/language combinations.

It seems to be fine:

$ dotnet publish
Microsoft (R) Build Engine version 17.0.0-preview-21302-02+018bed83d for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  All projects are up-to-date for restore.
  You are using a preview version of .NET. See: https://aka.ms/dotnet-core-preview
  clib -> C:\Users\alex\source\repos\zig-msbuild-sdk\src\samples\clib\bin\Debug\win-x64\clib.dll
  clib -> C:\Users\alex\source\repos\zig-msbuild-sdk\src\samples\clib\bin\Debug\win-x64\publish\

~/source/repos/zig-msbuild-sdk/src/samples/clib  master
$ ls bin/Debug/win-x64/publish/
clib.dll  clib.pdb

But there may be edge cases we aren't covering.

This might tie into:

• #8

Depends on: ziglang/zig#3287

It seems like arm-linux-gnueabihf means ARM v8 to Zig. We need a way to specify ARM v7 as that's what linux-arm means in .NET land. See: ziglang/zig#4911 (comment)

Zig has some support for WebAssembly, but I'm not sure how complete/usable it is.

This will depend on: dotnet/runtime#44636

It will also partially depend on:

• #9

Depends on: zigtools/zls#357

Depends on: ziglang/zig#8680

See: darlinghq/darling#863

Add a new LinkerReference item that can be used to specify libraries that should be searched for by the linker. So, <LinkerReference Include="pthread" /> results in -lpthread being passed.

Also add a new LinkerDirectory item to specify linker search paths. <LinkerDirectory Include="foo" /> turns into -Lfoo.

As seen here: https://github.com/alexrp/zig-msbuild-sdk/actions/runs/1042545644

It's generally fine to mix C++ code compiled for different ABIs as long as the code using each ABI is isolated in separate modules and those modules only talk through a C interface.

Unfortunately, things are not so simple when linking to a static library that contains C++ code. If that code is not compiled for the ABI being targeted, things break in all sorts of ways at link time. This is only really a problem on Windows where there are two major C++ ABIs: MSVC and Mingw-w64.

To enable users to link to static libraries compiled for the MSVC ABI, there needs to be a property to control the ABI on Windows. We should still default to the Mingw-w64 ABI since that's amenable to cross-compilation, but if Zig grows support for cross-compiling for the MSVC ABI one day, we will likely want to switch the default to that.

This isn't terribly useful right now, but will become useful once the .NET SDK gains full support for Apple platforms like iOS and watchOS that only support static linking.

This will require significant work in Zig, especially for cross-compilation.

See: ziglang/zig#5145

Builds aren't actually deterministic on Windows yet.

See: ziglang/zig#9432

Tracking issue for ProjectReference/PackageReference support.

The Zig compiler only enables this option when building a shared library (DLL on Windows). Do we need to pass it along with -rdynamic for symbols to be exported properly from an executable?

Something like:

• On Build, run zig fmt --check if EnforceCodeStyleInBuild is set.
• Add a Format target that actually formats source files (i.e. just zig fmt <sources>).

There's a lot of documentation here that should be moved to GitBook: https://github.com/vezel-dev/zig-sdk/blob/87c82c01e78e0aa122312d6187d07f65814aca5a/README.md

https://github.com/ziglang/zig/milestone/16 https://github.com/ziglang/zig/milestone/18

Depends on: ziglang/zig#9167

This only becomes relevant once the .NET SDK gains full support for Android.

There is some ongoing work on this in Zig:

• ziglang/zig#2443
• ziglang/zig#8885

NDEBUG exists to distinguish between Debug/Release, but that isn't quite enough to figure out the ReleaseMode.

See: ziglang/zig#11949

This allows generating a header file for C/C++ code to consume a Zig library.

This support is very incomplete in Zig right now.

But do we actually care? It doesn't seem like .NET cares too much about this RID anymore; it's only supported as a build target, not as a build host (which it used to be in the past).

See: ziglang/zig#11396

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2572.pdf

We can't entirely prevent users from creating non-deterministic builds, but we can at least enable some sensible compiler flags for this scenario.

In a similar vein to:

• #28

Unfortunately, Zig does not currently ship with these tools, so we would have to require users to install them.

Questions:

• Should we mandate a specific code style like zig fmt or let it be configurable?
• Should we try to detect the presence of these tools on disk or just go ahead and invoke them if the user asked us to?
• Should clang-tidy be tied to WarningLevel? Or should we maybe use AnalysisLevel/AnalysisMode?

Situation: Microsoft.Build.NoTargets-based project A references Zig.Sdk-based project B. Both have GeneratePackageOnBuild=true and both are RID-specific.

Issue: dotnet build -p A -r <rid> will fail with the following errors.

C:\Program Files\dotnet\sdk\6.0.100-preview.6.21355.2\Sdks\NuGet.Build.Tasks.Pack\build\NuGet.Build.Tasks.Pack.targets(222,5): error NU5118: File 'C:\Users\alex\source\repos\test\src\runtime\bin\Debug\linux-arm64\libcoreclr.so' is not added because the package already contains file 'runtimes\linux-arm64\native\libcoreclr.so' [C:\Users\alex\source\repos\test\src\runtime\runtime.cproj]
C:\Program Files\dotnet\sdk\6.0.100-preview.6.21355.2\Sdks\NuGet.Build.Tasks.Pack\build\NuGet.Build.Tasks.Pack.targets(222,5): error NU5019: File not found: 'C:\Users\alex\source\repos\test\src\runtime\bin\Debug\linux-x64\libcoreclr.so'. [C:\Users\alex\source\repos\test\src\runtime\runtime.cproj]

Some candidates (need to review each):

• -Wmicrosoft-abstract (see #37)
• -Wmicrosoft-anon-tag
• -Wmicrosoft-charize (already controlled by -fms-extensions)
• -Wmicrosoft-comment-paste (not supported in newer MSVC versions, and seems insane)
• -Wmicrosoft-cpp-macro (already controlled by -fms-extensions)
• -Wmicrosoft-enum-forward-reference (this is both a GNU and Microsoft extension, and controlled by appropriate flags)
• -Wmicrosoft-explicit-constructor-call (limited usefulness)
• -Wmicrosoft-fixed-enum (already controlled by -fms-extensions)
• -Wmicrosoft-flexible-array (already controlled by -fms-extensions)
• -Wmicrosoft-mutable-reference (I can't figure out what this even is, and it Clang doesn't seem to emit it)
• -Wmicrosoft-sealed (unnecessary as C++11 has final)
• -Wmicrosoft-static-assert (Clang has code for this diagnostic, but I suspect it's broken)
• -Wmicrosoft-union-member-reference

See: ziglang/zig#9187

We can probably generate these files based on a template at build time.

This can be done fully in parallel so it won't hurt build performance much. The advantage is that developers will always see build issues without having to build for every RID manually or rely on CI to catch the issues. Also, some build logic for Pack can be simplified.

I don't think we can use NoWarn; it might contain various warning codes that are specific to managed tools. We would have to somehow filter those out without accidentally removing warning names recognized by Clang. Better to use a new property.

Maybe something like:

<DisableWarnings>cast-align; enum-compare; parentheses</DisableWarnings>

It is possible to have a project with just the singular RuntimeIdentifier set and no RuntimeIdentifiers at all. _PackNativeAssets should handle this case properly.

See: https://reviews.llvm.org/D102517

See: dotnet/msbuild#6672

Here's where it happened on CI: https://github.com/alexrp/zig-msbuild-sdk/runs/3062030033?check_suite_focus=true#step:9:32

Zig doesn't emit the .eh_frame and .eh_frame_hdr sections by default. However, C/C++ compilers (including zig cc/zig c++) do. We should align the behavior as much as possible by default.

323f719 disabled building the samples on macOS in CI. Re-enable once cross-compilation from macOS is fixed.

-Wall -Wextra doesn't actually enable all Clang warnings. There are some additional warnings that we definitely want to enable at higher warning levels.

See: ziglang/zig#9223

With this, we can use our own cross-execution detection logic without having to exactly match Zig's.

See: https://clang.llvm.org/docs/JSONCompilationDatabase.html