Embedding the engine as a submodule and cmake module?

A question: does Urho3d have to be built first before it can be used as an external library in another cmake based project? I mean can I put the Urho3d git repo as a git submodule inside my project’'s git repo and somehow let my project’s cmakelist.txt drive the build of the URho3d tree together as part of the build process of my project?

The documentation for Urho 1.5 says URHO3D_HOME needs to point to the Urho3d build tree, which seems to imply that Urho3d has to be built first somewhere before projects using it can be built. In my project setup as described above, I have the full source tree of Urho3d inside my project’s source tree, but I cannot set URHO3D_HOME to point to a Urho3d source tree, or a subdirectory of it. It is convenient to be able to build everything via a single cmake invocation (and then make, xcode, etc.). Any way to get around this?

Thanks

It is possible. There was even a time when there was no Urho3D library target so users would have to build using the source code directly into their projects. Having said that, our current development direction is to keep things modularized. And yes, it means we have to build Urho3D as a library first and to use it as dependency, even for internal targets in our own Urho3D project. Of course there is nothing prevent you from doing thing the old way, however, that use case is not being tested or well supported anymore.

I really dislike the idea of having to install an SDK or a library to start working on my projects. That’s why i usually add libraries as submodules on my git projects and use CMake to statically link them to my application. Here’s a similar workflow:

github.com/Polytonic/Glitter

Bullet, Assimp, GLFW and others are added as submodules and, when i CMake my project, they get built and linked together. Much easier for everyone involved, self-contained and modular. Anyway, i’ve been looking for a way to do this with Urho without any luck. The whole building process seems very complex. Is there any way to achieve a similar workflow with this engine?

I’ve been running into issues with this as well. I spent a good week trying to get CMake to play nicely with Urho3D as a dependency for my project. I settled with generating my projects separately with the include/lib added in manually. Not the best solution, but it works. I would like to see a CMake setup with Urho3D as a dependency, though.

related discussion topic1701.html (Moderator note: topic is merged)

I think I have understood atai’s original question wrongly. When I first read it, somehow I understood it wrongly as the Urho3D source code would be used directly without using its CMake build system in the downstream project. However, if what you want to achieve is to let your own CMake build system to add Urho3D as a sub-directory by itself via CMake’s add_subdirectory() command then I think that is perfectly valid use case that we need to support. I think there are only a few places that we need to tweak to make this works.

Yes that was what I meant. Thanks in advance if this can be easily done!

Another way you can approach this problem is to use CMake’s ExternalProject module for automatically downloading, building, and installing Urho3D locally.

Yes, our build system has support building/installing Urho3D using ExternalProject_Add() for a while now. Still, that is a different use case than what being asked in this topic. With add_subdirectory(), the downstream projects can see Urho3D library as an internal CMake target.

Exactly, and that’s key in improving the build workflow, specially when you’re on a big team and with a solid CI/CD. People just have to clone the project, update the submodules and run Cmake. And our Cmake project is able to customize everything. That’s our workflow for everything: both external libraries (bullet, glfw, assimp, etc) and our internals (game logic is in a library, internal utilities, rendering lib, etc).

I think you are aware that Urho3D has “embedded” itself a number of 3rd-party libs that it depends on including Bullet. So while working in enabling the Urho3D’s build system to allow itself to be embedded by downstream project, I suppose we won’t change this internal dependency configuration. In other words, when you include Urho3D then you probably should exclude Bullet from being build separately again.

How so? The OP asked:

ExternalProject achieves exactly what the OP wants and what namic said:

Having Urho3D as an internal dependency in your project has its up- and downsides. For example, if you’re using an IDE such as KDevelop or CLion that uses CMakeLists.txt for project files, it will try to index the entire Urho3D project. This increases loading times of the project. When building, it also takes longer because it has to check all of Urho3D’s targets if they need to be updated. That can get quite annoying. Doesn’t Urho3D rebuild script bindings every time CMake re-runs? So every time you add a new header/source file to your project, Urho3D will re-generate script bindings and re-generate documentation.

If you’re using ExternalProject, the above problems are avoided, but it’s a little more complicated to set up properly. The best way to set up ExternalProject is to have it download and install Urho3D in the binary directory somewhere, then when CMake runs a second time, have it look for Urho3D in the binary directory using find_package() instead. If Urho3D is found then you skip your ExternalProject_add() call and incremental builds from that point on get a lot faster than if you were to use ExternalProject_add() all the time.

In the end you should try out both methods and see what’s best for your particular use-case.

Do not get me wrong. I am not saying using ExternalProject_Add() is bad. Both are valid use cases. Like you said, it really depends on what one project needs. We have fixed our build system about a year ago (I think) to support the ExternalProject_Add() use case, but at the moment our build system does not yet support the other use case. And this is what this topic is about. BTW, I have made this as a new issue in GitHub issue tracker so you can hope for its support sometime in the near future.

Ah ok, thanks for making this clear!

[quote=“namic”]I really dislike the idea of having to install an SDK or a library to start working on my projects. That’s why i usually add libraries as submodules on my git projects and use CMake to statically link them to my application. Here’s a similar workflow:

github.com/Polytonic/Glitter

Bullet, Assimp, GLFW and others are added as submodules and, when i CMake my project, they get built and linked together. Much easier for everyone involved, self-contained and modular. Anyway, i’ve been looking for a way to do this with Urho without any luck. The whole building process seems very complex. Is there any way to achieve a similar workflow with this engine?[/quote]

I just took a look at this, and I think having a version of Glitter/Chlorine with Urho3D is something newbies could really use. I know that many of us gave up on CMake for our own projects a long time ago, and just use our own project files instead.

Hi gyus,

I’m a newbie in Urho, trying to learn it from scratch for the last month, so don’t punch me too hard if I’m saying something obvious.
After some experiments I found the most convenient way working on a project with Urho is using it as external lib, but with some clarification:

  1. I’ve created git repo with Urho3D as a submodule and a MyProject directory on the same level.
  2. In MyProject I’ve got CMake config suitable for building my project, mostly like it is on wiki, but specified for MyProject. Everithing else made like it’s posted on wiki page “External library”.
  3. On the root level I’ve created scripts for build trees generating, thus I generate Urho3D lib and a project depending on it.
    So the root directory looks like:
    • Urho3D(submodule)
    • MyProject
    • UrhoBuildTree
    • ProjectBuildTree
    • a bunch of build generating scripts

It works like a charm in windows and linux builds, and simple to maintain.

What do you mean by build trees? You’re specifying, by hand, the Urho source files to build on your own cmake?

I did some work to allow using Urho3D via cmake add_subdirectory(). Check it out: github.com/r-ku/Urho3D/tree/cma … bdirectory

Sample CMakeLists.txt of parent project:

[code]cmake_minimum_required(VERSION 3.5)
project(Urho3D)

if (COMMAND cmake_policy)
cmake_policy (SET CMP0003 NEW)
if (CMAKE_VERSION VERSION_GREATER 2.8.12 OR CMAKE_VERSION VERSION_EQUAL 2.8.12)
# INTERFACE_LINK_LIBRARIES defines the link interface
cmake_policy (SET CMP0022 NEW)
endif ()
if (CMAKE_VERSION VERSION_GREATER 3.0.0 OR CMAKE_VERSION VERSION_EQUAL 3.0.0)
# Disallow use of the LOCATION target property - therefore we set to OLD as we still need it
cmake_policy (SET CMP0026 OLD)
# MACOSX_RPATH is enabled by default
cmake_policy (SET CMP0042 NEW)
endif ()
endif ()

set(CMAKE_CXX_FLAGS “${CMAKE_CXX_FLAGS} -std=c++11”)

set (CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/Urho3D/CMake/Modules)
add_subdirectory (Urho3D)
find_package(Urho3D)
include_directories (${URHO3D_INCLUDE_DIRS})

set(SOURCE_FILES Sample.h Sample.inl StaticScene.h StaticScene.cpp)
add_executable(_TestApp ${SOURCE_FILES})
target_link_libraries(_TestApp ${URHO3D_LIBRARIES} z pthread)
[/code]

There is one shortcoming though - main project still has to be called “Urho3D”. See project(Urho3D) in sample file. Reason for this is that urho’s build system uses CMAKE_PROJECT_NAME to check if you are building urho or linking to it. Sounds simple enough but in practice i failed to figure out how exactly to work-around this requirement. Any advice from people who are better familiar w/ urho’s build system would be greatly appreciated. In the meantime this is good compromise.

I don’t think it will work for initial case. After the add_subdirectory() call, the library does not exist yet, so the next find_package() command may not be able to find Urho3D library. At the time I wrote my last comment, I have thought through it once and I was clearer then than now of what it needs to be done. :wink:

But it does work just fine. This is because FindUrho3D.cmake takes care of this case already. As long as project name is “Urho3D”. Reason for this is that “PROJECT_NAME STREQUAL Urho3D” is scattered all around urho’s cmake scripts. Now i tried to substitute all instances of that comparison with custom-set variable. It works fine but as soon as project name changes - everything breaks. Be great if someone with better knowledge of build scripts (like you) could try my patch and script i posted above while changing project name in that script. I have a feeling we are no that far from a solution. Unfortunately cmake does not bend to my will…