Order of build matters with respect to git2go and Go cross compiler building

[ae6rt]

Thank you for git2go. Very handy.

While building a Docker container image suitable for building Go apps that could leverage git2go, I ran across something interesting.

The container Dockerfile also happens to include building the Go cross compilers for darwin and windows. If I build the container with this ordering of statements with respect to the cross compilers and git2go

 # Environment
 ENV PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/go/bin:/go/bin
 ENV GOPATH /go

 # Cross compilers 
 RUN cd /usr/local/go/src && GOOS=darwin GOARCH=amd64 ./make.bash --no-clean
 RUN cd /usr/local/go/src && GOOS=windows GOARCH=amd64 ./make.bash --no-clean

 # libgit2/git2go C binding
 RUN go get -d -u -v github.com/libgit2/git2go && cd /go/src/github.com/libgit2/git2go && git submodule   update --init && make test install

the resulting Go environment can successfully build a sample Go app that uses the git2go library.

However, if I reverse the order of building the cross compilers with the building of git2go, I cannot build the sample app. The sample app build in this case fails with

 root@e98ffd5673af:/go/src/t# go build
 # github.com/libgit2/git2go
 ../github.com/libgit2/git2go/blame.go:4:18: fatal error: git2.h: No such file or directory
  #include <git2.h>
              ^
 compilation terminated.

I don't know the reason for this, but wanted to make the observation here.

[carlosmn]

In your second example you're running 'go build', which is not going to work regardless of when you do it.

[carlosmn]

That is, if you're making 'go build' actually build git2go, it's not going to work no matter what. I you're building the corss-compiler after installing git2go, you've presumably made the timestamp of all the code in the go library/runtime be later than the build of git2go, so it tries to build it again, which is what won't work.

[ae6rt]

Thanks for the reply. Much appreciated.

I think you're making two separate points. The first point is do not try to build git2go using go build. I understand that, and I'm not doing that and never was doing that. The compilation failure I show which fails around git2.h occurs in the building of a sample app in package main located at sample app source path GOPATH/src/t/ (you can see this reflected in the shell prompt). This sample build is building an app that relies on previously built and installed git2go per your git2go README instructions. I'm sorry I was not more clear on that.

Your second point is the one that I think really matters. If I build the cross compilers after installing git2go , then building any sample app using the installed git2go will fail. I think that is what you mean.

Here is the successful Dockerfile in its entirety. Not shown now is the building of sample app that used git2go, which would have occurred after the last line (or in scripting in the container with "docker run -it tag bash" or some such).

https://gist.github.com/ae6rt/4074df9c41338feb9260

[carlosmn]

Yeah, I didn't notice you were building a different program with the build command at first.

Go's assumption that you can always just rebuild with its own tool is what's hitting us here. The way to work around this would be to link dynamically but that's not a very nice option when following the main branch.

I am thinking of creating a branch to stay at libgit2 v0.22 (once it releases Real Soon Now) so you can use 'go build' to work around this (and partially solve #143), but it would require a release of libgit2 to exist on the system (though that shouldn't be a huge issue).