Compiling with MSYS2-Mingw64

[huberp]

I try to compile with MSYS2-Mingw64. On Windows 11 Branch is "docking-inter" I don't need anima, I just want to make GLFW and ImGui work in Protoplug, which is a VST plugin scriptable with LUA. I want to only compile the stuff necessary.

Started to cmake it with /mingw64/bin/cmake -G"MinGW Makefiles" -DCMAKE_BUILD_TYPE=Release -DCMAKE_BUILD_TYPE=RelWithDebInfo -DIMPL_SDL=no -DGLFW_PATH="/C/dev/projects/builds/glfw-orig-build" -DLUAJIT_BIN="C:/dev/projects/builds/cimgui" .

Problem/Question 1: The readme.md is vague about where to point -DGLFW_PATH. Should it point to a cmake project? Should it point to a directory containing the glfw DLL? To the headers? A install Dir?

Then I go /mingw64/bin/mingw32-make.exe install Result: I ran into various compilation issues causec by missing includes. This issues I think I was able to solve by adding more include directories to CMakeLists.txt and redo the cmake step. Seems the include dirs I have added where just missing. Don't know how the project ever compiled,to be honest...

Problem/Question 2: Finally I ran into a number of compile errors like the console capture below. I was not able to get rid of these. It seems quite confusing because actually the missing classes like CanvasState are there, but somehow they don't get used. How can I make the project compile?

[ 64%] Building CXX object CMakeFiles/cimgui_base.dir/cimnodes_r/cimnodes_r.cpp.obj [ 68%] Building CXX object CMakeFiles/cimgui_base.dir/cimnodes_r/ImNodes/ImNodes.cpp.obj C:\dev\projects\LuaJIT-ImGui\cimnodes_r\ImNodes\ImNodes.cpp:35:1: error: ‘CanvasState’ does not name a type 35 | CanvasState gCanvas = nullptr; | ^~~ C:\dev\projects\LuaJIT-ImGui\cimnodes_r\ImNodes\ImNodes.cpp:133:5: error: ‘CanvasState’ does not name a type; did you mean ‘_CanvasStateImpl’? 133 | CanvasState PrevCanvas = nullptr; | ^~~ | _CanvasStateImpl C:\dev\projects\LuaJIT-ImGui\cimnodes_r\ImNodes\ImNodes.cpp:138:1: error: ‘CanvasState’ does not name a type 138 | CanvasState::CanvasState() noexcept | ^~~ C:\dev\projects\LuaJIT-ImGui\cimnodes_r\ImNodes\ImNodes.cpp:154:1: error: ‘CanvasState’ does not name a type 154 | CanvasState::~CanvasState() | ^~~

[sonoro1234]

Problem/Question 1: The readme.md is vague about where to point -DGLFW_PATH. Should it point to a cmake project? Should it point to a directory containing the glfw DLL? To the headers? A install Dir?

GLFW_PATH should point to the directory were it was installed after a compilation with cmake.

Problem/Question 2: Finally I ran into a number of compile errors like the console capture below. I was not able to get rid of these. It seems quite confusing because actually the missing classes like CanvasState are there, but somehow they don't get used. How can I make the project compile?

The compile errors could be generated because of your CMakeLists modifications. It would be better to solve first issue first. You should post cmake errors if there is any and in case there are not cmake errors your compile errors.

[huberp]

Thanks for your reply. Then lets's do it step by step, good approach.

May be let's start with some background, what is my goal. I'm a fan of protoplug. Protoplug is a VST Lua Scripting plugin. I have updated the initial code to compile to VSt3 and use Juce 6. Now I want to ImGUI to be able to do cool UIs as well. Right now I have hacked luapower thread and pthread into protoplug and a basic GLFW version... see https://www.kvraudio.com/forum/viewtopic.php?p=8496417#p8496417

1.) I have a working GFLW Build. It got installed here C:\DEV\PROJECTS\BUILDS\GLFW-ORIG-BUILD. I chose this path later in cmake for LuaJIT-Imgui. Content is: ├───bin │ glfw3.dll │ ├───include │ └───GLFW │ glfw3.h │ glfw3native.h │ └───lib │ libglfw3dll.a │ ├───cmake │ └───glfw3 │ glfw3Config.cmake │ glfw3ConfigVersion.cmake │ glfw3Targets-release.cmake │ glfw3Targets.cmake │ └───pkgconfig glfw3.pc

2.) I grabbed a fresh git clone into C:\dev\projects\LuaJIT-ImGui-Clean I have used this URl to clone it, right from the browser https://github.com/sonoro1234/LuaJIT-ImGui, which will clone the default branch named "docking_inter" 3.) I open MSYS2 Mingw64 shell. Msys2 comes with a variety of "shells". I choose the Mingw64 shell I have had to add some packages actually by pacman.I garbbed the latest cmake, cxx compilers to get things going, Stupid as I am I didn't keep record about which packages I have added ... 4.) I call cmake from folder /c/dev/projects/LuaJIT-ImGui-Clean /mingw64/bin/cmake -G"MinGW Makefiles" -DCMAKE_BUILD_TYPE=Release -DIMPL_SDL=no -DGLFW_PATH="/C/dev/projects/builds/glfw-orig-build" -DLUAJIT_BIN="C:/dev/projects/builds/cimgui" . 5.) Cmake output is -- The C compiler identification is GNU 11.3.0 -- The CXX compiler identification is GNU 11.3.0 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - failed -- Check for working C compiler: C:/dev/msys64/usr/bin/cc.exe -- Check for working C compiler: C:/dev/msys64/usr/bin/cc.exe - works -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - failed -- Check for working CXX compiler: C:/dev/msys64/usr/bin/c++.exe -- Check for working CXX compiler: C:/dev/msys64/usr/bin/c++.exe - works -- Detecting CXX compile features -- Detecting CXX compile features - done CMake Deprecation Warning at CMakeLists.txt:2 (cmake_minimum_required): Compatibility with CMake < 2.8.12 will be removed from a future version of CMake.

Update the VERSION argument value or use a ... suffix to tell CMake that the project does not need compatibility with older versions.

-- GLFW_PATHdefinedasC:/dev/projects/builds/glfw-orig-build -- Looking for pthread.h -- Looking for pthread.h - found -- Performing Test CMAKE_HAVE_LIBC_PTHREAD -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success -- Found Threads: TRUE glfwincludeis -- Configuring done -- Generating done -- Build files have been written to: C:/dev/projects/LuaJIT-ImGui-Clean

6.) Then in same folder I go make it /mingw64/bin/mingw32-make.exe install [ 4%] Building CXX object CMakeFiles/cimgui_base.dir/cimgui/cimgui.cpp.obj [ 8%] Building CXX object CMakeFiles/cimgui_base.dir/cimgui/imgui/imgui.cpp.obj [ 12%] Building CXX object CMakeFiles/cimgui_base.dir/cimgui/imgui/imgui_draw.cpp.obj [ 16%] Building CXX object CMakeFiles/cimgui_base.dir/cimgui/imgui/imgui_demo.cpp.obj [ 20%] Building CXX object CMakeFiles/cimgui_base.dir/cimgui/imgui/imgui_widgets.cpp.obj [ 24%] Building CXX object CMakeFiles/cimgui_base.dir/cimplot/cimplot.cpp.obj C:\dev\projects\LuaJIT-ImGui-Clean\cimplot\cimplot.cpp:5:10: fatal error: ./implot/implot.h: No such file or directory 5 | #include "./implot/implot.h" | ^~~~~~~ compilation terminated. mingw32-make[2]: [CMakeFiles\cimgui_base.dir\build.make:151: CMakeFiles/cimgui_base.dir/cimplot/cimplot.cpp.obj] Error 1 mingw32-make[1]: [CMakeFiles\Makefile2:84: CMakeFiles/cimgui_base.dir/all] Error 2 mingw32-make: *** [Makefile:135: all] Error 2

==> Ends with Error, missing include. That's where I started to add includes in the top level CMakeLists.txt and later having the errors I initialy reported...

[sonoro1234]

Are you sure than implot folder inside cimplot folder is not empty? In case it is you should do the cloning as explained in https://github.com/sonoro1234/LuaJIT-ImGui#cloning

[huberp]

Hey sonoro1234, no it isn't. I followed your steps to "recursive" check out...actually I know git modules and the basics about how to use them. And as I said, after I changed the includes in toplevel CMakelist.txt to... (just a cut out of the section following) _#general settings include_directories(cimgui/imgui) include_directories(cimplot/implot) include_directories(cimguizmo/ImGuizmo) include_directories(./cimguizmo_quat/imGuIZMO.quat/imGuIZMO.quat) include_directories(cimnodes/imnodes)

add_definitions("-DIMGUI_DISABLE_OBSOLETE_FUNCTIONS=1")

add_definitions(-DIMNODES_NAMESPACE=imnodes) include_directories(cimgui) include_directories(cimplot) include_directories(cimguizmo) include_directories(cimguizmo_quat) include_directories(cimnodes) include_directories(cimnodes_r/ImNodes) include_directories(cimnodes_r) include_directories(cimgui/imgui/backends) set(IMGUISOURCES ./cimgui/cimgui.cpp ... the compile went on which finally got me to the the imnodes_r problems with Canvas not defined.

here's a tree of the cimplot folder c:\dev\projects\LuaJIT-ImGui-Clean>tree /F cimplot C:\DEV\PROJECTS\LUAJIT-IMGUI-CLEAN\CIMPLOT │ .gitmodules │ cimplot.cpp │ cimplot.h │ LICENSE │ README.md │ ├───generator │ │ cimplot_template.cpp │ │ cimplot_template.h │ │ generator.bat │ │ generator.lua │ │ generator.sh │ │ │ └───output │ definitions.json │ definitions.lua │ overloads.txt │ structs_and_enums.json │ structs_and_enums.lua │ typedefs_dict.json │ typedefs_dict.lua │ └───implot implot.cpp implot.h implot_demo.cpp implot_internal.h implot_items.cpp LICENSE README.md TODO.md

[sonoro1234]

But with this cimplot tree is impossible to get C:\dev\projects\LuaJIT-ImGui-Clean\cimplot\cimplot.cpp:5:10: fatal error: ./implot/implot.h: No such file or directory

[huberp]

Hm, sorry to say. It actually is. I can only tell you what I get and what helped me to overcome this specific error. I think there's an assumption what the "." means in "./implot/implot.h" which not holds in every case. maybe it is due to windows or it is due to me using the latest cmake / make,I don't know. $ /mingw64/bin/cmake --version cmake version 3.23.2

$ /mingw64/bin/cmake --version cmake version 3.23.2

Let's make a little experiment. I take all the defined include directories from CMakelist.txt and just attach "./implot/implot.h" to see whether this file is available... as I said, it's just an experiment to verify what "." means and what I think it means.

include_directories(cimgui/imgui/./implot/implot.h) include_directories(cimplot/implot/./implot/implot.h) include_directories(cimguizmo/ImGuizmo/./implot/implot.h) include_directories(./cimguizmo_quat/imGuIZMO.quat/imGuIZMO.quat/./implot/implot.h) include_directories(cimnodes/imnodes/./implot/implot.h) include_directories(cimgui/./implot/implot.h) ... I would say ... no the file "implot.h" is actually not at any of these places.

BUT when I extend the includes with include_directories(cimplot) and do the same trick/experiment include_directories(cimplot/./implot/implot.h) this file is available...

[sonoro1234]

I dont get to understand your experiment. Also cimplot/./implot/implot.h is not a directory but a file.

In case of . meaning is not sure ./implot/implot.h could be changed in cimplot.cpp for implot/implot.h

[huberp]

It was just a "thought experiment". rational: If gcc sees #include "./implot/implot.h" then it goes through all directories it has been provided by the "-I" option. And if I assume that all cmake include_directories end up as part of "-I" then you probably get my "thought experiement": gcc will append "./implot/implot.h" to all include paths given by the "-I" option and tries to load the file.

[sonoro1234]

But #include"something" searches in current directory also and #include<something> searches in directories provided by the -I option.

One issue could be I am using mingw-w64 without MSYS2 for compiling. You could also try it by using cmake and mingw32-make from the windows standart cmd.

I also can compile commenting several include_directories as in:

include_directories(cimgui/imgui)
#include_directories(cimplot/implot)
#include_directories(cimguizmo/ImGuizmo)
include_directories(./cimguizmo_quat/imGuIZMO.quat/imGuIZMO.quat)
#include_directories(cimnodes/imnodes)
#add_definitions("-DIMGUI_DISABLE_OBSOLETE_FUNCTIONS=1")
add_definitions(-DIMNODES_NAMESPACE=imnodes)
include_directories(cimgui)

[huberp]

Interesting ... which version of cmake are you using? Asking because I found one hint that there might be changes between 2.8 and 3.9 of cmake https://stackoverflow.com/questions/48939337/changed-include-path-behaviour-from-cmake-2-8-x-to-3-9-x

Another Finding: I was looking for where the -I option is defined. I found following file C:\dev\projects\LuaJIT-ImGui-Clean\CMakeFiles\cimgui_glfw.dir\includes_CXX.rsp It contains these includes

_-I"C:/dev/projects/LuaJIT-ImGui-Clean/cimgui/imgui" -I"C:/dev/projects/LuaJIT-ImGui-Clean/cimplot/implot" -I"C:/dev/projects/LuaJIT-ImGui-Clean/cimguizmo/ImGuizmo" -I"C:/dev/projects/LuaJIT-ImGui-Clean/./cimguizmoquat/imGuIZMO.quat/imGuIZMO.quat" -I"C:/dev/projects/LuaJIT-ImGui-Clean/cimnodes/imnodes" -I"C:/dev/projects/LuaJIT-ImGui-Clean/cimgui" -isystem "C:/dev/projects/builds/glfw-orig-build/include"

And then there's a second file: C:\dev\projects\LuaJIT-ImGui-Clean\CMakeFiles\cimgui_base.dir\includes_CXX.rsp

_-I"C:/dev/projects/LuaJIT-ImGui-Clean/cimgui/imgui" -I"C:/dev/projects/LuaJIT-ImGui-Clean/cimplot/implot" -I"C:/dev/projects/LuaJIT-ImGui-Clean/cimguizmo/ImGuizmo" -I"C:/dev/projects/LuaJIT-ImGui-Clean/./cimguizmoquat/imGuIZMO.quat/imGuIZMO.quat" -I"C:/dev/projects/LuaJIT-ImGui-Clean/cimnodes/imnodes" -I"C:/dev/projects/LuaJIT-ImGui-Clean/cimgui"

Do you have the same file in your build? When did you last recreate things for cmake from scratch?

[sonoro1234]

mingw: i686-8.1.0-release-posix-dwarf-rt_v6-rev0\mingw32\bin cmake: cmake-3.16.3-win64-x64\bin

cimgui_glfw:

-IC:/LuaGL/gitsources/anima/LuaJIT-ImGui/cimgui/imgui -IC:/LuaGL/gitsources/anima/LuaJIT-ImGui/./cimguizmo_quat/imGuIZMO.quat/imGuIZMO.quat -IC:/LuaGL/gitsources/anima/LuaJIT-ImGui/cimgui -IC:/LuaGL/gitsources/BUILDS/SDL2/install/include/SDL2 -isystem C:/LuaGL/gitsources/BUILDS/GLFW/install/include

cimgui_base:

-IC:/LuaGL/gitsources/anima/LuaJIT-ImGui/cimgui/imgui -IC:/LuaGL/gitsources/anima/LuaJIT-ImGui/./cimguizmo_quat/imGuIZMO.quat/imGuIZMO.quat -IC:/LuaGL/gitsources/anima/LuaJIT-ImGui/cimgui -IC:/LuaGL/gitsources/BUILDS/SDL2/install/include/SDL2

When did you last recreate things for cmake from scratch?

Just now

[huberp]

Holly shit ... now I feel utterly stupid :-(

I think you gave the important tip above when saying "use windows command line". I think the solution is that I have to use /mingw64/bin/cmake -G"Unix Makefiles" when working in a Unix shell. Otherwise the paths with "\" are invalid ... omg... I'm so stupid.

[sonoro1234]

Let me know if this solved your issue. It could also be MSYS Makefiles.

[huberp]

It compiles! Thanks for your patience and for providing the hint to look in to path-formats

And after some little adaptions to the Lua Files to make them work in Protoplug, I was able to open a ImGui Window in Protoplug!