Fixing up some infrastructure so we can consume the libclang 8.0.0 packages #65

tannergooding · 2019-06-07T04:08:39Z

This adds some nuspecs for the libclang package to make it easier to create in the future. This also does some misc infrastructure upgrades to make it easier to consume the package once published.

tannergooding · 2019-06-07T04:09:18Z

Directory.Build.props

@@ -67,7 +67,7 @@

  <!-- Package references which are consumed by all projects -->
  <ItemGroup>
-    <PackageReference Include="Microsoft.Net.Compilers.Toolset" IsImplicitlyDefined="true" />
+    <PackageReference Include="Microsoft.Net.Compilers.Toolset" IsImplicitlyDefined="true" PrivateAssets="all" />


Needed to mark this as PrivateAssets="all" so that the product packages don't list it as a dependency.

tannergooding · 2019-06-07T04:11:15Z

Directory.Build.targets

@@ -15,6 +15,11 @@
    <DefineConstants>$(DefineConstants);$(OS)</DefineConstants>
  </PropertyGroup>

+  <!-- Settings that allow testing to work by default -->
+  <PropertyGroup>
+    <RuntimeIdentifier Condition="'$(RuntimeIdentifier)' == ''">$(NETCoreSdkRuntimeIdentifier)</RuntimeIdentifier>


The libclang package is setup using a runtime.json file, so tests can't run without a RID being specified (so the correct libclang` native dependency can be resolved). This sets the default to just be the same as the host SDK.

tannergooding · 2019-06-07T04:11:42Z

Directory.Build.targets

    <PackageReference Update="System.CommandLine.Experimental" Version="0.2.0-alpha.19174.3" />
-    <PackageReference Update="xunit" Version="2.3.1" />
-    <PackageReference Update="xunit.runner.visualstudio" Version="2.3.1" />
+    <PackageReference Update="xunit" Version="2.4.1" />


These were a few versions old. Upgrading to get perf and other minor benefits.

tannergooding · 2019-06-07T04:12:19Z

packages/libclang/LICENSE.TXT

@@ -0,0 +1,278 @@
+==============================================================================


LICENSE.TXT was taken directly from https://github.com/llvm-mirror/clang

tannergooding · 2019-06-07T04:12:57Z

packages/libclang/libclang.nuspec

+  <metadata minClientVersion="2.12">
+    <id>libclang</id>
+    <version>8.0.0</version>
+    <authors>Microsoft and Contributors</authors>


NuGet lists this as being the package authors/owners, not the binary authors/owners.

tannergooding · 2019-06-07T04:13:56Z

packages/libclang/runtime.json

@@ -0,0 +1,59 @@
+{
+  "runtimes": {


LLVM supports 12 platforms, of those, .NET Core supports 11 (no PowerPC support).

tannergooding · 2019-06-07T04:14:33Z

packages/libclang/runtime.json

+        "runtime.osx-x64.libclang": "8.0.0"
+      }
+    },
+    "sles-x64": {


The native dll is technically sles.11.3, but that isn't a valid RID

.NET supports sles.12 as the earliest version

tannergooding · 2019-06-07T04:16:04Z

sources/ClangSharpPInvokeGenerator/ClangSharpPInvokeGenerator.csproj

 <Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
-    <TargetFramework>netcoreapp2.0</TargetFramework>
+    <TargetFramework>netcoreapp2.1</TargetFramework>


netcoreapp2.0 went EOL (end of life) back in October of 2018

tannergooding · 2019-06-07T04:17:31Z

Once this is approved/merged, I can publish the libclang.8.0.0 nuget packages and can submit the PR consuming them.

libllvm is going to be a bit more complex as it requires building per RID (which is feasible, it just will take a bit of time 😄).

tannergooding · 2019-06-07T04:31:16Z

packages/libclang/libclang.nuspec

+    <owners>Microsoft and Contributors</owners>
+    <requireLicenseAcceptance>true</requireLicenseAcceptance>
+    <license type="expression">Apache-2.0</license>
+    <projectUrl>https://github.com/llvm-mirror/clang</projectUrl>


The license should definitely match the original binaries, but it might make sense to use the clangsharp project url, instead of theirs. Thoughts?

There is also the repository url a few lines down...

Actually, looks like NuGet lists projectUrl as

A URL for the package's home page, often shown in UI displays as well as nuget.org.

repository is listed as:

Repository metadata, consisting of four optional attributes: type and url (4.0+), and branch and commit (4.6+). These attributes allow you to map the .nupkg to the repository that built it, with the potential to get as detailed as the individual branch or commit that built the package. This should be a publicly available url that can be invoked directly by a version control software. It should not be an html page as this is meant for the computer. For linking to project page, use the projectUrl field, instead.

@mjsabby, what do you think of making projectUrl be https://github.com/microsoft/ClangSharp and repository be: <repository type="git" url="https://github.com/llvm-mirror/clang" branch="release_80" />?

I think that would satisfy both who created the package and where the sources were built from.

Sounds good.

Fixed that up, and also updated the nuspec to:

Explicitly list the content files (so a failure occurs if you forget to copy over the native library)

Reuse the same LICENSE.TXT file from the packages/libclang directory, so we don't need 12 copies of it.

tannergooding added 6 commits June 6, 2019 20:40

Adding a nuspec file for creating the libclang package.

aadb173

Marking Microsoft.Net.Compilers.Toolset with PrivateAssets="all"

9a1dc15

Updating xunit to 2.4.1

fc69342

Updating Microsoft.NET.Test.Sdk to 16.1.1

b1479fd

Set a RuntimeIdentifier by default so testing works by default

e14068f

Upgrading netcoreapp projects to 2.1, since 2.0 is end of life

c626d43

tannergooding commented Jun 7, 2019

View reviewed changes

mjsabby approved these changes Jun 7, 2019

View reviewed changes

Fixing up the nuspec and removing duplicated LICENSE.TXT files.

c5286b4

tannergooding merged commit 86f2c23 into dotnet:master Jun 7, 2019

tannergooding mentioned this pull request Jun 8, 2019

Fixing up some infrastructure so we can consume the libLLVM 8.0.0 packages dotnet/LLVMSharp#104

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fixing up some infrastructure so we can consume the libclang 8.0.0 packages #65

Fixing up some infrastructure so we can consume the libclang 8.0.0 packages #65

tannergooding commented Jun 7, 2019

tannergooding Jun 7, 2019

tannergooding Jun 7, 2019

tannergooding Jun 7, 2019

tannergooding Jun 7, 2019

tannergooding Jun 7, 2019

tannergooding Jun 7, 2019

tannergooding Jun 7, 2019

tannergooding Jun 7, 2019

tannergooding Jun 7, 2019

tannergooding commented Jun 7, 2019

tannergooding Jun 7, 2019

tannergooding Jun 7, 2019 •

edited

tannergooding Jun 7, 2019

mjsabby Jun 7, 2019

tannergooding Jun 7, 2019

		@@ -0,0 +1,278 @@
		==============================================================================

Fixing up some infrastructure so we can consume the libclang 8.0.0 packages #65

Fixing up some infrastructure so we can consume the libclang 8.0.0 packages #65

Conversation

tannergooding commented Jun 7, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tannergooding commented Jun 7, 2019

Choose a reason for hiding this comment

tannergooding Jun 7, 2019 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tannergooding Jun 7, 2019 •

edited