![orx game engine orx game engine](https://www.mycplus.com/mycplus/wp-content/uploads/2020/09/Lifetris-480x270.png)
With just one line of configuration I could substitute such orxPlugin_Display at compile time without loosing benefits of being aligned to last orx vanilla version. Just to make an example, assume I have a modified orxPlugin_Display that can expose the GLFW window identifier to the orx host application. This would allow plugin injection on a vanilla orx version just by overriding a dependency using conan.
#Orx game engine code#
In the same time allows users to automatically build orx and dependencies in case a pre-build for such exotic configuration does not exists.ĭivide orx code base in multiple packages: This gives a you a quite standard way to create and distribute pre-built binaries. Users will use conan directly in their development flow and just add something like " and they will obtain all needed stuff to build the game. You simply create a packet for each dependency (if vanilla may be they are already available) and declare on conan recipe that you need such packet. No more need to have a complete custom package management with rebol, downloading zips, etc. More important, it fits really well with proposal 2. I know you may dislike CMake (It's really ugly and generates a lot of garbage, syntax sucks) but it's a de facto standard and it's better than having a custom modified old premkake 4 version. : Hello, I have some proposals regarding orx dev-ops that may help to add flexibility in building orx with different configurations and plugins.