Broken include paths when building without submodules about abaddon HOT 3 CLOSED

so i guess whats happening is that include_directories puts thirdparty/simpleini in the include list, and the ../../discord/foo turns into thirdparty/simpleini/../../discord/foo which resolves to discord/foo which happens to work out? would correcting the 2 broken #includes not be sufficient to fix the issue here? i guess i just dont see how this issue is particular to dependencies/submodules other than thats just what happened to cause it to compile correctly despite the broken paths.
as for making all the includes relative to the base directory thats a good idea and might be something worth doing from now on. i guess that would just look like a (target_)include_directories(${CMAKE_CURRENT_SOURCE_DIR})? (as u can tell im not much of a CMake expert)

also i guess re. your last point i should try and have the CMakeLists.txt look for simpleini and include as a submodule if its not found in the same kinda way i do ixwebsocket? or a find module

from abaddon.

so i guess whats happening is that include_directories puts thirdparty/simpleini in the include list, and the ../../discord/foo turns into thirdparty/simpleini/../../discord/foo which resolves to discord/foo which happens to work out?

That's exactly what's happening here. I wouldn't have noticed it if there was just some other directory two directories below the repo root in the include path.

would correcting the 2 broken #includes not be sufficient to fix the issue here?

would definitely be, but it isn't a very elegant solution (I hope I made that clear in my initial issue description).

i guess i just dont see how this issue is particular to dependencies/submodules other than thats just what happened to cause it to compile correctly despite the broken paths.

It is definitely not directly related to submodules, but it make a compilation fail when building from a source tarball (apart from vendored dependencies, of course).

as for making all the includes relative to the base directory thats a good idea and might be something worth doing from now on. i guess that would just look like a (target_)include_directories(${CMAKE_CURRENT_SOURCE_DIR})? (as u can tell im not much of a CMake expert)

Yes, the approach I recommend is just including the source directory (in this case, ${CMAKE_CURRENT_SOURCE_DIR}). In other projects (e.g. where all sources are below src) I would include that src directory.
As a rule of thumb, just try to make the #include statements look uniform and easily readable.
This usually just means including the source directory and (if present) a header directory (which doesn't exist in this case).

And I recommend not using include_directories() but rather target_include_directories() so the settings only apply to certain targets. But in simple CMake projects there isn't much of a difference, so it's more or less not important which one you use.

also i guess re. your last point i should try and have the CMakeLists.txt look for simpleini and include as a submodule if its not found in the same kinda way i do ixwebsocket? or a find module

Well, since simpleini is not very distro maintainer friendly (it really wants to be included as a submodule), it is best to write a find module to look for the header file in common directories (standard include directory, e.g. /usr/include).

To make builds more independent of the particular build machine, it might also be better to enforce either vendored or system-wide dependencies with configure-time options. But that's not such a big issue in this case. I've just had experience with projects like polybar which check for software installed on the system at compile time and configure their project's features accordingly. This is, of course, easy to use, but is very intransparent if e.g. polybar gets installed before one of those hidden dependencies and the user is facing the problem that polybar misses support for this certain feature, because polybar didn't see the hidden dependency installed at compile time. Still, this issue doesn't apply here, so it's not that important.

To sum it up, here's my recommendation:

• Make all #include statements for header files which reside in the repository relative to the repository root without ./ or ../
• Add target_include_directories(... ${CMAKE_CURRENT_SOURCE_DIR}) in CMakeLists.txt
• Write a find module for simpleini
• Search for simpleini using the find module
• (optionall) Add options to enforce either using vendored or system-wide dependencies

from abaddon.

i'll close this since the root issue should be gone. i'm still not super clear on what youre referring to with the last bullet point but if its still a concern then i'd make a new issue for it specifically (my guess is you mean an option that forces all or nothing for the dependencies). im not too concerned with the #include paths for now but ill probably start converting them as i end up touching the files. ill probably have a find module for simpleini in soon.

from abaddon.