-
Notifications
You must be signed in to change notification settings - Fork 44
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
module: build failure #43
Comments
I'd blame #18 |
the reason is, that both: cimplot.* and cimgui.* should be in the same directory OR the path to cimgui.h in cimplot generator should be set manually. Otherwise, cimplot.h searches for cimgui.h in its directory (in our case #include "../cimgui/cimgui.h" and now it is #include "cimgui.h" thats the reason of this failure |
The inclusion of cimplot by default here rubs me in the wrong way anyway, it introduces a ton of complexity and ImPlot is not a part of Dear ImGui anyway...
|
Well, I almost got it to work: diff --git a/backend.cpp b/backend.cpp
index 556bda4..9913e09 100644
--- a/backend.cpp
+++ b/backend.cpp
@@ -4,8 +4,8 @@
#define CIMGUI_USE_OPENGL3
#include "backend.h"
-#include "cimgui/cimgui.h"
-#include "cimgui/cimgui_impl.h"
+#include "cimgui.h"
+#include "cimgui_impl.h"
#include "thirdparty/glfw/include/GLFW/glfw3.h" // Will drag system OpenGL headers
// [Win32] Our example includes a copy of glfw3.lib pre-compiled with VS2010 to
diff --git a/cimplot_funcs.go b/cimplot_funcs.go
index 22ad6fb..1a6e66e 100644
--- a/cimplot_funcs.go
+++ b/cimplot_funcs.go
@@ -1,5 +1,7 @@
package cimgui
+// #cgo CFLAGS: -Icimgui -Icimgui/generator/output
+// #cgo CXXFLAGS: -Icimgui -Icimgui/generator/output
// #include "extra_types.h"
// #include "cimplot_structs_accessor.h"
// #include "cimplot_wrapper.h" Now, I get these errors:
I don't know how to fix them yet, but it finds all the headers it needs at least... |
Welp, I found a bag of worms... See this CMakeLists.txt. It wasn't even a "real" CMakeLists.txt from cimgui. It was an amalgamation of cimgui, glfw backend and cimplot This is wrong on many levels. There shouldn't be any "prebuilt" libraries in projects using CGo. They should be compiled from source. Dependency on GLFW backend and cimplot adds another bag of problems I'm not even sure where to start. I'll try to fix all this, but I'd rather start from removing glfw and cimplot dependency, making "cimgui" wrapper correct and then adding things back one by one. |
I think we should provide prebluit binaries. We shouldnt assume everyone has proper c/cpp compiles installed. |
Yeah, I did some investigations and building libraries during "go get" is not that great in all cases. For now, it only builds on Linux (only 1 precompiled lib here). I've temporarily removed GLFW backend and implot to make things easier. I will add them later in the way that will not require libimgui.a to NOT contain implot functions and I want cimgui-go to not depend on GLFW in any way. Like I previously said, I don't use GLFW. Some people might want to use SDL/raylib. Current cimgui-go forces users to embed GLFW code into their binaries. This is not great. Also, turns out git submodules cannot be used. When I tried to import cimgui-go using "go get" for ebiten-imgui, I got errors about cimgui.h not being there because "go get" doesn't fetch submodules. (running example) So, ideally we should ship all needed headers inside cimgui-go. But I think we should do some form of "git submodule" system where we'll have a file like:
and have a GitHub action named "update cimgui" which will automatically pull the corresponding version into the repo, build all libraries and commit it. We should always know which version of cimgui was used in a specific commit/build of all libraries. For cimplot and GLFW backend... Well, I need to think. I can deal with cimplot being a part of cimgui which I can't get rid of, but having to depend on GLFW - this I cannot accept. |
My two cents: You need to create a new CMakeLists.txt ( as done in https://github.com/sonoro1234/LuaJIT-ImGui) which picks whatever you want to use (cimgui, cimplot and glfw backend for example). cimgui and cimplot are ok as submodules but for glfw you can use find_package or FetchContent (as done in https://github.com/cimgui/cimgui/blob/68483775b3d7594eb14d296ec002ac11683882c9/backend_test/example_glfw_opengl3/CMakeLists.txt#L65) Then you could use github Releases (https://github.com/AllenDang/cimgui-go/releases) if you wish to provide binaries so that user doesn`t need to compile. (Althought user will be able to compile if he/she wants to do it) |
Also: In the cmake file you can have a variable USE_XXX_BACKEND to customize build for using GLFW, SDL or any other |
Hello. Thanks for the tips. However, users of Go libraries typically don’t ever compile anything or use CMake (unless go lib includes compilation via cgo commands, e.g. go-gl/glfw). The only way to not require a C compiler is to use cgo and compile the lib on the fly. This is also OK for me. But Go lib users won’t ever use CMake… but we could usr it internally, of course. |
@eliasdaler let me know if I can help you somehow |
Here are some steps that I propose we do for now.
This file will be used as a documentation for us (to know which version of cimgui, cimplot and glfw we have).
I won't have much time to work on cimgui-go myself this week, but I'll be able to review PRs. |
Actually, ushort vs uint thing is a bit more complicated... By default cimgui generates the files without IMGUI_USE_WCHAR32... So if we want unicode, we need to run generators ourselves. But the results should not go to "cimgui" and "cimplot" directories - they should be left as-is. Instead, we should place them in some "prebuilt" directory, e.g. "prebuilt/include/cimgui.h" ... and later configure cgo's search paths to use these files when compiling Go. Well, this is pretty complicated... |
sadly, it complains about cimgui_impl.h form backend.go
well, but I don't actually understand, why to stop using git submodules, since you propose exactly the same solution but without git submodules. |
Did you add
Hmm, yeah, I thought there were other improvements to CI, but there weren't. However: the previously commited 3rd party directories were not versioned properly and contained modifications to CMakeLists.txt of cimgui. So yeah, we can revert and fix that, or we could just remove submodules and add 3rd party libs properly this time... Storage reasons - doesn't matter even if it actually did it like this (but I don't think it does). We'll need to add a different sources for 3rd party libs anyway... |
Okay, I'll try making something later today to make exactly what I want.
|
So, while this is being fixed, I suppose I can use https://github.com/AllenDang/giu in the meantime. Also, can someone elaborate on it? I assume this cimgui-go will be taking over as soon as more things are in place? I really like that cimgui-go can essentially generate wrapper code in Go based on C/C++ header files. It's nice way to keep things up to date, but currently it's not clear which one I should use as both seems to be active... |
@eliasdaler any updates? |
Sure @Chillance! GIU works like a charm!
cimgui-go is just a wraper of imgui, while Also, giu is going to migrate to use this repo in future |
I think you should do that in the meantime. I really want to use this package so badly, but I just cant compile it. |
Reverted. |
@andraantariksa try now, it should work |
The last two reverts about git submodules should have helped. |
Hi, I'm having trouble building the latest code
The text was updated successfully, but these errors were encountered: