-
Notifications
You must be signed in to change notification settings - Fork 2
Home
The library produced by this repository is an extended (LibLLVM-C) API that extends the official LLVM-C API surface. As little extension as possible is used to keep things simpler but some extensions were needed to support managed wrappers. This is intended to provide managed .NET wrappers for LLVM.
Building a native library and containing NuGet package is a complex ordeal. Ensuring that works across multiple back-end build hosts is no simple feat. (There have been several over the years for this project). Thus the build is managed by PowerShell scripts and is mostly independent of the actual automated build system. The actual integration uses an "adapter" pattern to adapt the back-end to run the PowerShell scripts for the build.
This is the root script of the full build used by the back-end integrations.
.\Build-All.ps1 [-Configuration='<Release|Debug>'] [-ForceClean] [-SkipLLvm]
| Option | Description |
|---|---|
| Configuration | Determines the configuration to build, automated builds ALWAYS use a release build, but local use can create a Debug build |
| ForceClean | This options completely cleans all build artifacts to replicate what the automated build will see |
| SkipLLvm | [Mutually exclusive with -ForceClean] optimization for local loop builds to skip the fetch and build of LLVM core libraries |
A Debug build of the native libraries is rarely needed but is sometimes indispensable when debugging problems in calling the native code. Given the overall resources required to build a debug version and the limits of public OSS builds and package stores like NuGet, the only way to get a debug version of the native library is locally. (Actual time to generate depends on the CPU used. a 4 core multi-threaded system with only an HDD can go several hours (overnight). Whereas a 24 core i9 with all SSD can be done in under an hour.)
This will build LibLLVM for a given RID1 and produce a NuGet Package for it. Each RID is allowed to build in parallel. Such builds produce a per RID binary AND the NuGet Package to contain it.
This will build the outer RID neutral "meta" package. This references all supported RIDS AND includes the header files to access them. The header files also serve as in input to the tool that generates the handle wrappers in managed code. Since this can run in parallel in an automated build it cannot use the C# project system built in support for NuGet packaging. That support requires all referenced packages to exist but since this is run in parallel they don't exist yet. Thus, it requires a lower level nuspec file and build from that.
1 At present the only supported RID is win-x64 but the design is to allow any platform supported by .NET.