Skip to content

Publish NuGet packages with Debug version of libgit2 #16

@nulltoken

Description

@nulltoken
Member

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 libgit2/libgit2sharp#1125 and finding potential libgit2 leaks with nice stacktraces.

/cc @jeffhostetler

Activity

bording

bording commented on Jul 9, 2015

@bording
Member

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

bording commented on Jul 9, 2015

@bording
Member

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

nulltoken commented on Jul 9, 2015

@nulltoken
MemberAuthor

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

jeffhostetler commented on Jul 10, 2015

@jeffhostetler

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:

  • Release mode libgit2sharp using release mode NativeBinaries (for normal production use).
  • Debug mode libgit2sharp using release mode NativeBinaries (for casual developers using libgit2sharp)
  • Debug mode libgit2sharp using naked/local libgit2.dll (for advanced usage)

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @nulltoken@bording@jeffhostetler

        Issue actions

          Publish NuGet packages with Debug version of libgit2 · Issue #16 · libgit2/libgit2sharp.nativebinaries