Urho3D Library Plugin Projects

[SirNate0]

It seems to me that the build system could be made to allow "Plugin" projects to be added to the Urho3D project by using CMake's ExternalProject features. Basically, my idea is that in building the Urho3D library, we could allow an argument (URHO3D_PLUGINS) to specify a list of ExternalProject targets that would be built with Urho3D and then added to the library file.

As a very minimal proof of concept, this demonstrates the idea, though it doesn't actually use the built libraries for anything, so more work is definitely needed if we want to do it.

cmake_minimum_required(VERSION 3.15)

project(MyProject)

set (EXT_PROJECTS "fmt GIT_REPOSITORY https://github.com/fmtlib/fmt.git PREFIX ${CMAKE_BINARY_DIR} INSTALL_COMMAND echo skip-install;earcut GIT_REPOSITORY https://github.com/mapbox/earcut.hpp.git INSTALL_COMMAND echo skip-install" CACHE STRING "; separated list of ExternalProject's to add." FORCE)
include(ExternalProject)

foreach(EXT_PROJECT IN LISTS EXT_PROJECTS)
    set( EXT_LIST ${EXT_PROJECT} )
    separate_arguments(EXT_LIST)
    message("Adding Project: '" ${EXT_PROJECT} "'")
    ExternalProject_Add(${EXT_LIST})
endforeach()

One thought was this might allow better integration of different scripting languages. Rather than having them built directly with Urho3D, the script bindings can be separate projects, but the build system would still allow integrating them with the library itself, rather than as a second library to use in the game's project.

[eugeneko]

Rather than having them built directly with Urho3D, the script bindings can be separate projects, but the build system would still allow integrating them with the library itself, rather than as a second library to use in the game's project.

I don't quite understand what's the goal here. I mean... what exactly should I get as user from this? Can you elaborate, please?

[SirNate0]

The idea would be to allow additional script bindings and other modular features as separate projects. For example, I started on an attempt to create Python bindings for Urho. Rather than one day ending up with say 3+ different scripting subsystems in the Urho codebase, these projects (one day including Lua and AngelScript) could be moved to different repositories, but the bindings could still be built with the rest of Urho with just the addition of a variable passed into CMake, without having to copy/download/build the binding projects manually.

So the user's get nothing directly with Urho, but it would (hopefully) allow integration of additional well-contained features/libraries in an easier manner (e.g. The Spark/IMGUI implementations here https://github.com/fredakilla/Urhox, or Python bindings that might depend on python to generate the bindings - not necessarily a dependency we want to add to Urho itself).

Presently, I would say that "library that depends on Urho to be used in an separate Urho project" is not a very well supported arrangement. Or at least, I had enough issues with it when I tried that I just copy the IMGUI stuff directly to my project, rather than trying to build the intermediate library. Technically, this doesn't fix that issue, but it hopefully makes it less of an issue by making the "build the library into Urho" alternative simpler.

Does that clarify the goal? (I'm still not sure it's a great idea, hence this is a discussion and not an issue, but I thought of it this morning and since the initial quick example seemed successful I thought the discussion worthwhile.)

[eugeneko]

Maybe I just cannot really see beyond the prototype you shown.
What would be the functional difference between user doing ExternalProject_Add in their CMakeLists (like they can do now), and your proposal for the engine build system?
I feel like I am missing some important piece here.

[SirNate0]

That is a reasonable alternative, I suppose. I think the main difference would be that multiple user projects could be built from the single Urho(+plugins) build. I know for my projects, at least, virtually all of them have used the same set of extra code (ImGui, some serialization code I wrote, and fmt string formatting). Most of the code I just copy to new project folders (excepting fmt which was integrated with Urho). Script bindings especially have proven to take a fairly long time to compile, so it would be nice to only have to do it once with a build of Urho rather than for each new project.

That said, I don't know that I think it's a necessary feature, I just think it may be interesting to explore it. So if I make further progress on some automated script bindings (Python or Lua) I might attempt this idea (I'm open to just having those integrated directly with Urho, though, especially if it is the Lua bindings, if others think this approach is odd).