plugins {
id 'dev.nokee.cpp-application'
}
// Set the target operating system and architecture for this application
application {
targetMachines = [
//machines.linux.x86_64,
//machines.windows.x86,
machines.windows.x86_64,
//machines.macOS.x86_64
]
dependencies {
implementation fileTree('libs/imgui-1.89.3/')
}
}
I have a simple Hello World programm, that compiles fine. But if I just add a line "#include “imgui.h” ", gradle returns with a hint that C++ compiler failed, and more details about are in build/tmp/output.txt.
In the output.txt-file, I finde tons of lines like this:
cc1plus.exe: warning: C:.…\libs\imgui-1.89.3\backends\imgui_impl_allegro5.cpp: not a directory
cc1plus.exe: warning: C:.…\libs\imgui-1.89.3\backends\imgui_impl_allegro5.h: not a directory
cc1plus.exe: warning: C:.…\libs\imgui-1.89.3\backends\imgui_impl_android.cpp: not a directory
cc1plus.exe: warning: C:.…\libs\imgui-1.89.3\backends\imgui_impl_android.h: not a directory
…
What do I wrong?
There is also a very huge sample file to compile (imgui_demo), if I copy it into my main file, I get similiar errors.
Yes, it would be very nice if @Daniel_L could take a look on it.
Gradle compiles fine, if I threw the files simply into the source folder, but this will result in a mess very fast, so this is not an option for properly work.
But fortunately, I found another solution. The nokee plugin is able to crawl subfolders in the source folder. So, instead to simply put all files in the source code and header directory, I add a subfolder ‘imgui’, put all files in, in sum two folders, one with source code and one with the headers, and nokee builds it fine.
So, I have order and structure in my source files. Nice working, not that dependency mess from earlier days.
Sorry for missing this. In theory, you have the right idea for adding a dependency to a location on the file system. Unfortunately, in practice it doesn’t easily work because implementation is a bucket of dependencies that compile, link and run time extends from each requiring different kind of files (roughly headers, objects, dynamic lib respectively). We would still want to support this at some point (with a sample) and it would be very similar to what you did but you would need to use headerSearchPaths dependency bucket. The particularity with that bucket is that it’s created, per-source set, so for C++, the bucket would be named cppHeaderSearchPaths. I would need to try it out to see if all the work here is done and working accordingly.
The alternative is to use includes task property on CppCompile task. From memory, I believe it would be along the line of application.tasks.configureEach(CppCompile) { includes.from("<path/to/headers>") }
For linking, you can use LinkExecutable/LinkSharedLibrary and the libs task property.
I will check tomorrow to write a more evolved sample for this.
Thanks for your reply. Sorry that I’m short in time yet, I read and brain-process your post in the weekend, I just want to leave a short reaction here.
Just for short: The Imgui framework comes without dependencies except the standard library. It seems they did great work to keep implementers far from typical C pain.