search

libgit2 / libgit2sharp.nativebinaries

MIT License
29 stars 63 forks source link

Support package.json magic #40

Closed ethomson closed 8 years ago

ethomson commented 8 years ago

Apparently .NET Core type builds will:

a) eschew msbuild magic, and b) place native binaries according to some directory hierarchy conventions.

Fixes #39

bording commented 8 years ago

I believe that most of the other scripts have references to the libgit2 path that will also need to be updated to make sure everything is in the right place when the package is built.

ethomson commented 8 years ago

The tragic disappointment of this change means, of course, that we'll reopen https://github.com/libgit2/libgit2sharp/issues/1170. HA HA.

@bording did you happen to file a bug against mono?

bording commented 8 years ago

The tragic disappointment of this change means, of course, that we'll reopen libgit2/libgit2sharp#1170. HA HA.

I randomly was thinking about this the other day, and realized this exact thing, but apparently forgot about it again before I had a chance to mention it. :disappointed:

Unfortunately, I never found the time to actually set up a Bugzilla account at https://bugzilla.xamarin.com and go through the process of getting a decent but report filed. :cry:

So, support nuget3-style native dependencies, or mono?

bording commented 8 years ago

Actually wait, if the props file and dllmap file still use the lib folder, won't that still put things in the right place?

bording commented 8 years ago

The question is what sort of change have to happen to the actual loading code to make this work in both scenarios? I'm not sure how you're supposed to be referencing these native libraries from managed code when using this .NET Core runtimes magic.

ethomson commented 8 years ago

Actually wait, if the props file and dllmap file still use the lib folder, won't that still put things in the right place?

Hmm. That would be nice. That seems reasonable. I was hoping to get a 1:1 mapping between what's in the nuget package and what ends up on the filesystem, but there's no need for that, I suppose (except my ever-decreasing sanity.)

ethomson commented 8 years ago

The question is what sort of change have to happen to the actual loading code to make this work in both scenarios? I'm not sure how you're supposed to be referencing these native libraries from managed code when using this .NET Core runtimes magic.

There shouldn't be any changes, if I understand correctly. .NET 4.whatever will still run msbuild as it used to. .NET Core won't run msbuild at all, so it will look for the magic paths.

bording commented 8 years ago

Hmm. That would be nice. That seems reasonable. I was hoping to get a 1:1 mapping between what's in the nuget package and what ends up on the filesystem, but there's no need for that, I suppose (except my ever-decreasing sanity.)

That also would have required changes here to make it look somewhere other than 'lib'.

There shouldn't be any changes, if I understand correctly

So .NET Core must understand the runtime ids that are in the nuget package, and then uses those paths when processing the DllImport attribute. If that's how it works, then yeah, it seems like it should work in both cases.

Maybe one day in the future this will be supported everywhere, and the extra path manipulation code could be removed, and this could all be simplified. Hah!

ethomson commented 8 years ago

Okay, well, some manual testing suggests that this is working for .NET 4 (not .NET Core) on Windows. I'm going to merge this so that I can spin an actual native nuget package (not a prerelease).

If this is terrible then of course we can revert it.