Add dummy.go to glfw source directory

[pwaller]

Implemented with this shell fragment:

for x in $(find */*/glfw/* -type d); do
  echo $'package dummy\n// This package exists to support 'go mod vendor'. See #251' > $x/dummy.go
  git add $x/dummy.go
done

Fix #251.

[pwaller]

@gustafj @junxie6 - if either of you report this PR solves your problem, then I'll merge it.

[gustafj]

Hi @pwaller, sorry for the extremely late reply ;( and thanks for the attempt at solving the issue!

Unfortunately this does not solve the problem, I did a bit of reading and it seems that go mod prunes unneeded packages, which I think is the cause of the dummy.go files also being removed.

In order to verify this I did this:

1. clone or go get the https://github.com/go-gl/example.git repo
2. cd /example/gl21-cube
3. go mod init
4. go mod edit -replace github.com/go-gl/glfw/v3.3/glfw=github.com/pwaller/glfw/v3.3/glfw@issue-251
5. go mod vendor -v
6. go build -v -mod vendor cube.go

github.com/go-gl/glfw/v3.3/glfw
github.com/go-gl/gl/v2.1/gl
# github.com/go-gl/glfw/v3.3/glfw
vendor/github.com/go-gl/glfw/v3.3/glfw/c_glfw.go:4:10: fatal error: glfw/src/context.c: No such file or directory
    4 | #include "glfw/src/context.c"
      |          ^~~~~~~~~~~~~~~~~~~~
compilation terminated.

As you can see the build fails, and looking at the output from tree (see below) its obvious that the glfw/src folder is missing ;(

$ tree vendor/
vendor/
├── github.com
│   └── go-gl
│       ├── gl
│       │   ├── LICENSE
│       │   └── v2.1
│       │       └── gl
│       │           ├── conversions.go
│       │           ├── debug.go
│       │           ├── package.go
│       │           └── procaddr.go
│       └── glfw
│           └── v3.3
│               └── glfw
│                   ├── build.go
│                   ├── c_glfw_darwin.go
│                   ├── c_glfw.go
│                   ├── c_glfw_linbsd.go
│                   ├── c_glfw_windows.go
│                   ├── context.go
│                   ├── error.c
│                   ├── error.go
│                   ├── GLFW_C_REVISION.txt
│                   ├── glfw.go
│                   ├── go.mod
│                   ├── input.c
│                   ├── input.go
│                   ├── LICENSE
│                   ├── monitor.c
│                   ├── monitor.go
│                   ├── native_darwin.go
│                   ├── native_linbsd.go
│                   ├── native_windows.go
│                   ├── time.go
│                   ├── util.go
│                   ├── vulkan.go
│                   ├── window.c
│                   └── window.go
└── modules.txt

The module imported and used should be correct as it at least lists the module as replaced (see below), and a go build -v cube.go without vendoring (the default) succeeds.

$ go list -m all
github.com/go-gl/example/gl21-cube
github.com/go-gl/gl v0.0.0-20190320180904-bf2b1f2f34d7
github.com/go-gl/glfw/v3.3/glfw v0.0.0-00010101000000-000000000000 => github.com/pwaller/glfw/v3.3/glfw v0.0.0-20191124215638-f22e7dfab44d

A possible solution might be to explicitly import the dummy.go using the _ to get it through the "pruning" process, although I have not tried that myself.

[pwaller]

I got a bit of insight reading Russ's comments:

Sorry, but the model for go builds is that what's needed to build a package is in that directory, not subdirectories. The way gen2brain/aac-go is structured, modifying the C source code in the subdirectories will not trigger a rebuild. Instead your build will use stale cache entries. The C code needs to be moved up to the package directory to make it build properly, not to mention vendor properly.

Perhaps what we need to do is have the C files living alongside the go modules, I wonder? That doesn't seem ideal, of course.

@gustafj please try out importing the dummy package and report back (ideally with a pull request!). My cycles are very limited, but if there is a fix available and I can easily verify it fixes things, I will merge it.

[pwaller]

Ping @gustafj @dmitshur for helping thinking about this. Is it close to resolving the issue? Or shall I close this PR to make space for someone else to take a crack at solving it?

[pwaller]

Superseded by #280.