make GLFW C revision a part of input to Go build cache #269
Comments
|
A friend of mine just hit a related issue, when they tried to diagnose an issue by editing the C files, they found that the build cache meant that it wouldn't actually pick up the new files. My workaround was this: Not ideal. I know we shouldn't be editing the files but it can be useful for diagnostics. The only other way I'm aware of that we could fix this in principle on the glfw side is to put the C files into the same directory as the package. AIUI, this would result in Go building those C files. So we'd have to have a package per platform, or #ifdef toggles, essentially. I don't see a neat way which allows us to drop in the upstream glfw sources, at a glance. @dmitshur do you have any other ideas? Do we have to live with the behaviour as it is? |
@pwaller My suggestion is:
(I'm not sure if you missed it in the original issue report.) Maybe it should be an unexported constant instead of a comment. Both are probably fine. |
|
Oh, I see you were referring to editing C files for debugging specifically. Given how rarely that happens, and it's done by package developers, I'm okay with them having to be mindful of the build cache for now. Let's fix this problem for users of the package first (what this issue is about), then we can see if there's a reasonable way to also fix it for developers. I don't think we should do it if it complicates things too much. |
This is a workaround for the issue described in go-gl#269. Go unfortunately doesn't consider the C source files as part of its build cache calculation. Therefore, invalidate it by writing a hash which is computed across the full C source directory. This hash is only updated when `go generate` is called, but this will at least help the majority of users, when glfw is updated. Resolves go-gl#269.
This is a workaround for the issue described in go-gl#269. Go unfortunately doesn't consider the C source files as part of its build cache calculation. Therefore, invalidate it by writing a hash which is computed across the full C source directory. This hash is only updated when `go generate` is called, but this will at least help the majority of users, when glfw is updated. This is encoded in grab-upstream.sh which is used for updating the sources. This hash is intended to be protected from divergance by CI, too. Resolves go-gl#269.
This is a workaround for the issue described in go-gl#269. Go unfortunately doesn't consider the C source files as part of its build cache calculation. Therefore, invalidate it by writing a hash which is computed across the full C source directory. This hash is only updated when `go generate` is called, but this will at least help the majority of users, when glfw is updated. This is encoded in grab-upstream.sh which is used for updating the sources. This hash is intended to be protected from divergance by CI, too. Resolves go-gl#269.
This is a workaround for the issue described in go-gl#269. Go unfortunately doesn't consider the C source files as part of its build cache calculation. Therefore, invalidate it by writing a hash which is computed across the full C source directory. This hash is only updated when `go generate` is called, but this will at least help the majority of users, when glfw is updated. This is encoded in grab-upstream.sh which is used for updating the sources. This hash is intended to be protected from divergance by CI, too. Resolves go-gl#269.
This is a workaround for the issue described in go-gl#269. Go unfortunately doesn't consider the C source files as part of its build cache calculation. Therefore, invalidate it by writing a hash which is computed across the full C source directory. This hash is only updated when `go generate` is called, but this will at least help the majority of users, when glfw is updated. This is encoded in grab-upstream.sh which is used for updating the sources. This hash is intended to be protected from divergance by CI, too. Resolves go-gl#269.
|
I've merged #310 as a solution to this (currently only implemented for v3.3), since #309 upgraded the sources to v3.3.3 and it seems important that infected caches don't confuse things in hard-to-detect ways as users who may have built prior to v3.3.3 try to pull this in. It addresses both of our use cases, I think, by having the hash reflect the files as they are on disk at the time of invoking go generate. go generate is invoked when |
From https://golang.org/cmd/go/#hdr-Build_and_test_caching:
There's currently a problem where updating the GLFW C version does not invalidate the Go build cache for the
github.com/go-gl/glfw/v3.3/glfwpackage.We have a
GLFW_C_REVISION.txtfile that tracks the revision of the GLFW C library being used.We can rename the
GLFW_C_REVISION.txtfile to something likeglfwcrev.goand include the GLFW C revision as a comment:Then changing the GLFW C revision will cause one of the .go files to become different, and the old build cache will no longer get in the way.
This is somewhat related to #251 and #258.
The text was updated successfully, but these errors were encountered: