Build without VCPKG

[std-microblock]

I personally preferred to use git submodule to manage dependencies. Here's how I get it working.

1. Manually add dependencies of RmlUi.

I'm using GL3 backend with GLFW.

So freetype and glfw is added.

2. Create fake OpenGL::GL target.

(If #684 is merged, this step can be skipped)

add_library(opengl INTERFACE)
add_library(OpenGL::GL ALIAS opengl)

Cheat RmlUi as there's a OpenGL::GL target.

3. Import and create aliases for GLFW and Freetype

add_subdirectory(external/glfw)
add_library(glfw::glfw ALIAS glfw)
add_subdirectory(external/freetype)
add_library(Freetype::Freetype ALIAS freetype)

4. Build and enjoy :)

The issue is for reference only. I'll also be happy if the developer can make the process easier!

Final CMakeLists:

### Dependencies for GUI
set(BUILD_SHARED_LIBS OFF)
add_subdirectory(external/glfw)
add_library(glfw::glfw ALIAS glfw)
add_library(opengl INTERFACE)
add_library(OpenGL::GL ALIAS opengl)
add_subdirectory(external/freetype)
add_library(Freetype::Freetype ALIAS freetype)
add_subdirectory(external/RmlUi)
set(RMLUI_BACKEND GLFW_GL3)
add_subdirectory(external/RmlUi/Backends)

[mikke89]

Thanks a lot. I'm sure this can be helpful to other users.

There are of course many different ways to include libraries in C++, and we want to support them all. It would be nice to have some examples and tests people could look at. But I think you demonstrate here nicely that it is fairly straightforward, especially now after our CMake rewrite for RmlUi 6.0, and your PR will help too :)

I do already have some private tests that tests a lot of different build setups, such as using CMake add_subdirectory like here, using an in-source build, using the library installed, and using vcpkg. I'll see if I can find the time to clean those up and add it to the repository, both as examples and tests.

[hyblocker]

I've got a more complex example with all optional dependencies in a similar manner to the above. I'll post it when I have the time to clean it up.

[std-microblock]

Thanks a lot. I'm sure this can be helpful to other users.

There are of course many different ways to include libraries in C++, and we want to support them all. It would be nice to have some examples and tests people could look at. But I think you demonstrate here nicely that it is fairly straightforward, especially now after our CMake rewrite for RmlUi 6.0, and your PR will help too :)

I do already have some private tests that tests a lot of different build setups, such as using CMake add_subdirectory like here, using an in-source build, using the library installed, and using vcpkg. I'll see if I can find the time to clean those up and add it to the repository, both as examples and tests.

For other libraries that support mutable building systems, The solution to the issue is to write buildfiles for all of the building system that might be used. For example a project might use gn, cmake, bazel and makefile at the same time. They will write a CMakeLists, a bazel build file, a gn file and a makelists at the same time. We shouldnt consist on using a single building system.

If we want to only support one building system to reduce the complexity of the library, It shouldn't be the vcpkg but should be the CMake. As the most widely used c plus plus building system, many other building system provided some compatibility layers towards cmake, some even supports using cmake libraries directly, xmake for instance.

using voice input, plz ignore any grammar error :)

[mikke89]

Oh, we definitely won't add any other build systems anytime soon, CMake is what we've got and it's pretty much the industry standard. And we don't want to maintain multiple build systems, that effort can be much better spent elsewhere. Earlier, I meant build setups as in using the installed library, vs in-source build on so on.