search

libgit2 / libgit2sharp.nativebinaries

MIT License
28 stars 62 forks source link

Publish NuGet packages with Debug version of libgit2 #16

Open nulltoken opened 9 years ago

nulltoken commented 9 years ago

This would greatly ease the job of troubleshooting libgit2 issues discovered through LibGit2sharp bug reports/regressions.

Another usage of this would be to allow us to run a weekly scheduled build of LibGit2Sharp leveraging https://github.com/libgit2/libgit2sharp/pull/1125 and finding potential libgit2 leaks with nice stacktraces.

/cc @jeffhostetler

bording commented 9 years ago

Hmm, how do you see this working? I wouldn't think we'd want to move to always packaging the Debug version only. Most of the time I'd think people would want a Release build to go along with the Release build of LibGit2Sharp.dll.

bording commented 9 years ago

Maybe some sort of NativeBinaries.Debug package that's built in addition to the regular package?

Then LibGit2Sharp could depend on the Debug package, and when building the LibGit2Sharp package, it could list the regular, non-debug version for its dependency?

Hmm, that might work.

nulltoken commented 9 years ago

Maybe some sort of NativeBinaries.Debug package that's built in addition to the regular package?

Indeed, that's the idea

Then LibGit2Sharp could depend on the Debug package, and when building the LibGit2Sharp package, it could list the regular, non-debug version for its dependency?

Interesting. I was thinking about something more complicated (during the scheduled build, patch the packages.config file, then trigger a NuGet update command, but your proposal seems very attractive.

/cc @ethomson @jamill

jeffhostetler commented 9 years ago

I'm still getting used to the NativeBinaries way of building and running things, My original thoughts were that we could have a periodic (maybe daily or weekly) build/test run that would directly build both libgit2 (with -DMSVC_CRTDBG=ON) and libgit2sharp (with LEAKS_CRTDBG defined), and run all the tests (and maybe complain if were leaks).

The value there is that leaks get reported in the logs and we see the failures. The actual built bits are disposable at that point (since we'll never want anyone to use debug bits in production and we're all probably going to have our own local builds of everything and just want to fix/address the leaks as we get time (or as we're creating them)).

I'm not sure how that plays with the NativeBinaries way of building. (I'm not saying it's wrong, just that I haven't studied it enough yet.) I'm just not sure we need a long-term archive of debug versions of NativeBinaries. (If we do go that route then do we need both plain NativeBinaries.Debug and NativeBinaries.Debug.CRTDBG, for example?)

Personally, I'd rather just build my own libgit2 debug bits so that they match the version of the libgit2 source I'm working on, so I'd shy away from a pre-built NativeBinaries.Debug.

Maybe we should tweak the libgit2sharp build scripts/csproj to have a third configuration option:

and then use that last one when looking for leaks and throw away the bits.