vezel-dev / zig-sdk Goto Github PK
View Code? Open in Web Editor NEWAn MSBuild SDK for building Zig, C, and C++ projects using the Zig compiler.
Home Page: https://docs.vezel.dev/zig-sdk
License: BSD Zero Clause License
An MSBuild SDK for building Zig, C, and C++ projects using the Zig compiler.
Home Page: https://docs.vezel.dev/zig-sdk
License: BSD Zero Clause License
This allows generating a header file for C/C++ code to consume a Zig library.
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
.
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
In a similar vein to:
Unfortunately, Zig does not currently ship with these tools, so we would have to require users to install them.
Questions:
zig fmt
or let it be configurable?clang-tidy
be tied to WarningLevel
? Or should we maybe use AnalysisLevel
/AnalysisMode
?323f719 disabled building the samples on macOS in CI. Re-enable once cross-compilation from macOS is fixed.
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.
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>
Depends on: zigtools/zls#357
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.
Builds aren't actually deterministic on Windows yet.
See: ziglang/zig#9432
Lines 238 to 250 in f3f8941
See: ziglang/zig#11949
NDEBUG
exists to distinguish between Debug
/Release
, but that isn't quite enough to figure out the ReleaseMode
.
Depends on: ziglang/zig#8680
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:
Depends on: ziglang/zig#9167
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:
We can't entirely prevent users from creating non-deterministic builds, but we can at least enable some sensible compiler flags for this scenario.
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?
There's a lot of documentation here that should be moved to GitBook: https://github.com/vezel-dev/zig-sdk/blob/87c82c01e78e0aa122312d6187d07f65814aca5a/README.md
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.
See: ziglang/zig#9187
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]
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.
See: ziglang/zig#9223
With this, we can use our own cross-execution detection logic without having to exactly match Zig's.
zig-sdk/src/sdk/build/Vezel.Zig.Sdk.Pack.targets
Lines 43 to 45 in 034b922
It is possible to have a project with just the singular RuntimeIdentifier
set and no RuntimeIdentifiers
at all. _PackNativeAssets
should handle this case properly.
-Wall -Wextra
doesn't actually enable all Clang warnings. There are some additional warnings that we definitely want to enable at higher warning levels.
Depends on: ziglang/zig#9222
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)
This only becomes relevant once the .NET SDK gains full support for Android.
There is some ongoing work on this in Zig:
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.
Some candidates (need to review each):
-Wmicrosoft-abstract
-Wmicrosoft-anon-tag
-Wmicrosoft-charize
-fms-extensions
)-Wmicrosoft-comment-paste
-Wmicrosoft-cpp-macro
-fms-extensions
)-Wmicrosoft-enum-forward-reference
-Wmicrosoft-explicit-constructor-call
-Wmicrosoft-fixed-enum
-fms-extensions
)-Wmicrosoft-flexible-array
-fms-extensions
)-Wmicrosoft-mutable-reference
-Wmicrosoft-sealed
final
)-Wmicrosoft-static-assert
-Wmicrosoft-union-member-reference
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
We can probably generate these files based on a template at build time.
See: ziglang/zig#11396
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).
It blocks win-x86
completely (see ziglang/zig#8531) and breaks various other platform/language combinations.
Something like:
Build
, run zig fmt --check
if EnforceCodeStyleInBuild
is set.Format
target that actually formats source files (i.e. just zig fmt <sources>
).Tracking issue for ProjectReference
/PackageReference
support.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.