Skip to content

Make the Linux/MacOSX experience slightly more delightful #837

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
nulltoken opened this issue Sep 20, 2014 · 5 comments
Open

Make the Linux/MacOSX experience slightly more delightful #837

nulltoken opened this issue Sep 20, 2014 · 5 comments

Comments

@nulltoken
Copy link
Member

#786 brings under the light the fact that there's still a huge room for improvment regarding the following topics

  • How to build libgit2
  • How to run the tests against the generated binaries

Currently, all of the above is being automagically done by the build.libgit2sharp.sh script.

I can think of two options:

  • Add some documentation in the script header describing what the script does, where the binaries are generated
  • Break up the script into two scripts (ie. build and runtests)

There are certainly others ways to solve this.

Thoughts?

@Therzok
Copy link
Member

Therzok commented Sep 20, 2014

We should consider integrating the libgit2 build script into msbuild and simplify the build process to a simple xbuild run.

@carlosmn
Copy link
Member

Splitting the scripts has value, since the most convenient way to run the tests on unix is to run the script, due to the load path handling, but it wants to rebuild libgit2 every time.

If you modify the C# code, this adds extra steps; you can add the correct library path export, but you need to remember to do it on each of your terminals and remember whether you're on a fruity computer or not.

@carlosmn
Copy link
Member

As we've seen from some issues, it's not necessarily that clear even on Windows, which loads stuff willy-nilly, how to get the library in the right place if you're not used to dealing with non-CLR code.

Some bindings have decided it's easier to bundle everything together in the same shared object. While it looks like it's possible to mix managed and unmanaged code in a DLL, it doesn't seem too workable, since the managed code is the same for all platforms.

@Therzok how would this xbuild run react to a failing built step due to missing dependencies? We still need to put the resulting .so/.dylib in the library load path for testing, which would likely mean shelling out (possibly via env) in order to make the loader aware of the modified load path, since you can't change it from inside the process itself.

@Therzok
Copy link
Member

Therzok commented Nov 13, 2014

I'll take a look at this. My proposed changes:

  • Split the build script into build and runtests.
  • The build script will have a timestamp check for the libgit2 external directory to see whether to rebuild it. Add an option to force the rebuild of libgit2. Otherwise, just xbuild it.
  • Probably apply the above to the windows script too.

@Therzok
Copy link
Member

Therzok commented Nov 13, 2014

@carlosmn have no idea on that.

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

No branches or pull requests

3 participants