go vendor does not work

[asmaloney]

I feel like I'm missing a piece of the puzzle 🧩 to getting started with this...

Edit: In case you don't want to read this whole thread:

It's a go vendor issue (which they won't fix). go vendor won't vendor any directories unless they contain a go file (which C/C++ libraries obviously won't) and there's no way to request that it do so.

--

I'm trying to use it like any other go package.

go get "github.com/AllenDang/cimgui-go"
go mod vendor

I import:

import (
    "github.com/AllenDang/cimgui-go"
)

It shows up properly in my go.mod:

require github.com/AllenDang/cimgui-go v0.0.0-20221118092040-698de0565142

But when I go build my application:

% go build
# github.com/AllenDang/cimgui-go
In file included from vendor/github.com/AllenDang/cimgui-go/backend.go:20:
In file included from ./backend.h:3:
./cimgui_wrapper.h:3:10: fatal error: 'cimgui/cimgui.h' file not found
#include "cimgui/cimgui.h"
         ^~~~~~~~~~~~~~~~~
1 error generated.

If I clone this repo separately and go build it seems to build fine.

I'm guessing it has to do with the way vendored modules work? Any idea how to fix it?

[gucio321]

Hi @asmaloney I met this problem as well could you confirm, that it works with vendoring-mode off? if so, I'm going to report it as bug to go

[asmaloney]

could you confirm, that it works with vendoring-mode off

If I:

• delete vendor/
• run go get "github.com/AllenDang/cimgui-go"
• DO NOT run go mod vendor
• run go build

It builds properly.

[gucio321]

ok, thank you

I've opened https://github.com/golang/go/issues/56920

[eliasdaler]

Read these threads... wow, what a silly behaviour on Go's part. Does this mean that we won't be able to merge https://github.com/AllenDang/cimgui-go/pull/18?

[asmaloney]

Does this mean that we won't be able to merge https://github.com/AllenDang/cimgui-go/pull/18?

Since the golang devs have refused to fix what is a major bug from everyone else's perspective - having imgui deps as submodules would actually help.

Then one can write a Makefile to run go mod vendor and then pull down the submodules & put them in the vendor dir. Then we can run make vendor instead of go mod vendor.

A bit more work and bit more fragile, but might be the least-bad solution?

[gucio321]

@asmaloney @eliasdaler I got an idea to create files like doc.go (they would be supposed to do nothing but will say go to copy these directories into vendor) insnide cimgui and cimplot, but idk if it wouldn't conflict with submodules, need to check

EDIT nevermind - it will not work

[asmaloney]

Yes, I looked through all of this and another option is to try to use dummy files, but you would need to put one in every single directory that needs to be copied. I saw an example of this somewhere and it's messy & error prone.

Since this project doesn't control the external ones, you would also need to run an extra command anyways to make it happen, so I figured if we have proper submodules people can do what they like - e.g. I would use Makefiles some other people might write a shellscript.

It's a total mess & I don't get why the golang people don't want to help solve it, but 🤷

[gucio321]

well, so we may try write a design-doc and fill a proposal in go's repo or do a workaround a create a Makefile like @asmaloney suggested

[gucio321]

Does this mean that we won't be able to merge https://github.com/AllenDang/cimgui-go/pull/18?

not really - this problem doesn't depend on cimgui/cimplot being submodules or not; it is caused by lack of go files in cimgui/cimplot dirs

Yes, I looked through all of this and another option is to try to use dummy files, but you would need to put one in every single directory that needs to be copied. I saw an example of this somewhere and it's messy & error prone.

yah and it will not work, because git will complain about these files

[asmaloney]

I think it's not going to be totally straightforward no matter how we do it because of the way it works.

I can take a look at the Makefile idea and see how it works & to get a better picture.

I wish go mod vendor had a facility to say "I know what I'm doing - copy all git submodules" for a specific repo. Or to give it a list of directories to include explicitly. It just seems so... half-done. 😞

[eliasdaler]

I think another option is to make a CI job which will recursively clone all depenency repos into this repo and just commit all changes to "main". This way, you'll get fully self-contained repo without problems of git submodules.

[asmaloney]

git submodules aren't the problem - we want those!

It's go vendor. It won't vendor any directories unless they contain a go file - which C/C++ libraries won't.

[gucio321]

generally in current implementation it isn't impossible to resolve this issue. We can crate a "dummy" go package in C dependencies folde so that go toolchain considers this a go package. The thing is, that simply

/// Package doc is a dummy to include this directory in go vendor
package doc

isn't enough, because GO will complain about "C/C++ source files not allowed if not using CGO or SWIG". We need to design some additional import "C" stuff to make it all working. Anyway, removing frozen tag.

[gucio321]

ref: https://github.com/go-gl/glfw/blob/master/v3.3/glfw/glfw/include/dummy.go we can modify Makefile to do something loke this.

[gucio321]

I forgot about this, but #238 reminded me that we're missing one more thing that glfw does. In glfw, th main module imports all the dummy packages so that they don't get lost by go vendor.

[gucio321]

imo is done, let me know if it doesn't work.