Conan package

[zamazan4ik]

Hello, Do you know about Conan? Conan is modern dependency manager for C++. And will be great if your library will be available via package manager for other developers.

Here you can find example, how you can create package for the library.

If you have any questions, just ask :-)

[paroj]

patches are welcome though

[paroj]

you can find a conanfile.py for ogre at https://github.com/AnotherFoxGuy/conan-OGRE

[AnotherFoxGuy]

There is an issue when packaging OGRE for Conan, for some reason the linker flags end up as libs

[ 64%] Linking CXX shared library ../../lib/libOgreOverlay.so
/usr/bin/ld: cannot find -loptimized
/usr/bin/ld: cannot find -ldebug
collect2: error: ld returned 1 exit status

This didn't happen with 1.9

[paroj]

could be this: https://cmake.org/pipermail/cmake-developers/2013-March/018422.html

with 1.10 we started using upstream find scripts for zlib and freetype

[paroj]

can you try linking against the ZLIB::ZLIB and Freetype::Freetype imported targets

instead of this https://github.com/OGRECave/ogre/blob/9c2055e69962921e867331e2f224cec2d5f7f215/Components/Overlay/CMakeLists.txt#L24

[AnotherFoxGuy]

can you try linking against the ZLIB::ZLIB and Freetype::Freetype imported targets

That works, thanks!

[KonradNoTantoo]

I have a recipe for 1.12.5 here: https://github.com/KonradNoTantoo/ogre3d_conan

Binaries can be downloaded from my bintray: conan remote add utopia https://api.bintray.com/conan/konradnotantoo/utopia

[DrewImm]

Ogre could really use a standardized conan recipe to make setup & installation a breeze - especially for new-comers, and to integrate with conan projects. There's a few floating out there (@AnotherFoxGuy, @KonradNoTantoo, and some private ones). Unfortunately, they don't seem to be updated regularly and they didn't work quite as I had hoped. Inspired heavily by RoR and Konrad, I built a recipe to address my own requirements and assumptions:

Requirements:

• Must be easy to use and well-documented
  • Should not require any experience building ogre to use
• Must be maintainable
  • Should depend on the official repositories, not forks
  • Should checkout ogre's proper release tag, which can be updated as new ogre versions are released
• Must automate the entire download, build, and install process
• Should follow ogre's existing cmake build as much as possible
• Should expose all of Ogre's cmake options
  • Some exceptions include options that would break the integration, such as directories and cmake settings
• Should allow for automated copy of bin/ and Media/ to the user-space project
• WIP: Should optionally allow for scaffold of example/base SampleApplication

Assumptions:

• Default behavior should not be to use system-wide ogre dependencies
  • This seems to add additional complexity & overhead to the other user's recipes
  • This breaks the requirement "Should depend on official repositories, not forks"
  • The user may not require ogre's dependencies elsewhere
  • This can be bypassed in user-space with OGRE_BUILD_DEPENDENCIES

How it works:

1. Installs Linux dependencies, if on Linux
2. Clones ogrecave/ogre
   1. Checks-out proper release tag
   2. Clones submodules
3. Cmake configure/build/install
4. Sets include directories & libaries based on components/plugins
5. (Optional) Copies bin/ and Media/ to project

Proposal

• Continue testing & gather feedback
• Give this recipe to Ogre
• Setup official bintray or conan repo
• PR a link into BuildingOgre guide
• Maybe use for CI as discussed on https://forums.ogre3d.org/viewtopic.php?t=95698?

Thoughts?

[paroj]

looks good to me. Feel free to create a PR adding the conanfile. I will then look into extending our CI to automatically publish artifacts

[DrewImm]

Thanks for taking a look @paroj

I'll continue testing this and will be back with a PR in the next week or so

It may be best for me to try to PR it into the official conan repo instead. Any thoughts or concerns?

[paroj]

why not both?

[KonradNoTantoo]

@DrewImm Your work looks great. I hope mine could help you in some way.

As you correctly summarized, I don't have much time for OSS currently. Yet, there's a good chance I'll come back to Ogre in a few months. If so, I'll try to take some time then to use your tools and give you feedback.

[DrewImm]

@paroj I think it may be a good idea to have a single source of truth to keep things dry. Putting it in the official conan repo means that users don't have to add an extra remote, although probably not a huge deal

@KonradNoTantoo Thanks, couldn't have done it without you!

The hope is that wherever we host the recipe, that it will be the community's to decide what's best

[ggulgulia]

is anyone working on this ? It's 2022 and there's still no conan-recipe for ogre on the official CCI

[AnotherFoxGuy]

is anyone working on this? It's 2022 and there's still no conan-recipe for ogre on the official CCI

That is because freeimage is still missing from the CCI

But there is a recipe that I try and keep up to date here: https://github.com/AnotherFoxGuy/ror-conan-recipes

[paroj]

That is because freeimage is still missing from the CCI

Ogre works just fine without freeimage by using STBI

[AnotherFoxGuy]

Ogre works just fine without freeimage by using STBI

But isn't DDS support still missing from STBI?

[paroj]

DDS has its own codec and will work without either Freeimage or STBI

[djdesant]

For making it work i had to manually edit the conan (v1.47.0) "settings.yml" file by adding the missing target "Emscripten" and "Neutrino" like this:

os_target: [Windows, Linux, Macos, Android, iOS, watchOS, tvOS, FreeBSD, SunOS, Arduino, Neutrino]

os: Windows: subsystem: [None, cygwin, msys, msys2, wsl] WindowsStore: version: ["8.1", "10.0"] Linux: Macos: version: [None, "10.6", "10.7", "10.8", "10.9", "10.10", "10.11", "10.12", "10.13", "10.14"] Android: api_level: ANY iOS: version: ["7.0", "7.1", "8.0", "8.1", "8.2", "8.3", "9.0", "9.1", "9.2", "9.3", "10.0", "10.1", "10.2", "10.3", "11.0", "11.1", "11.2", "11.3", "11.4", "12.0", "12.1"] watchOS: version: ["4.0", "4.1", "4.2", "4.3", "5.0", "5.1"] tvOS: version: ["11.0", "11.1", "11.2", "11.3", "11.4", "12.0", "12.1"] FreeBSD: SunOS: Arduino: board: ANY Emscripten: Neutrino: version: ["6.4", "6.5", "6.6", "7.0", "7.1"]

look hier: https://github.com/conan-io/conan/blob/39b1bb3d32576323927033d86fce6f641a1a8518/conans/client/migrations_settings.py#L2013-L2019

[AnotherFoxGuy]

OGRE has been added to the conan center https://conan.io/center/ogre https://github.com/conan-io/conan-center-index/pull/11102

[ggulgulia]

Hello everyone. I was one of the contributors of the first package of OGRE on Conan-Center-Index. Since OGRE is large and I'm not expert in OGRE, I realized a couple of weeks ago that the Ogre Plugins cannot be linked against a small application.

I've opened an issue on Conan-Center-Index about this : https://github.com/conan-io/conan-center-index/issues/11715

Can someone please help me here. The information on how to propagate plugin information to consumers of ogre conan recipes will be further helpful to create other versions of ogre-conan-recipes.

Thanks

[KonradNoTantoo]

@ggulgulia Ogre plugins are loaded, at runtime, usually based on a specific configuration file. This file is conventionally named plugins.cfg in the applications installation directory. In the case of conan, it would make sense to me (but this can be discussed) to distribute a plugins.cfg file that points to each plugin distributed through conan.

There's an example on this page.

[ggulgulia]

@KonradNoTantoo thanks for the reply.

I've been working on figuring out how to use the conan packaged plugins of Ogre.

How binaries and headers packaged with conan work ?

(Probably you already know this but doesn't hurt to repeat the information)

• Conan doesn't permit to package library provided cmake file (read more here) which means that the onus to propagate the information correctly falls on the conan recipe.
  • This has been done correctly for the core library components
  • For the plugins this has to be modified
• Conan generates the information of core library components of ogre for the consumers in FindOGRE.cmake or OGREConfig.cmake
• For the plugins we have to generate the information for plugins in file called libs/cmake/conan-official-OGRE-variables.cmake and use this file in FindOGRE.cmake or OGREConfig.cmake

Packaging and using plugins.cfg file

In the case of conan, it would make sense to me

Now that I roughly understand how plugins are used by OGRE, it makes sense to me to also generate the information through conan.

• For e.g the attribute PluginFolder inside plugins.cfg file can point to the absolute path OGRE/libs that contains the Plugins libraries.
• plugins.cfg file can be generated by the conan recipe But in this respect I've the following questions:
  • Where should the plugins.cfg file be placed ? inside bin directory ?
  • How the build system (CMakeLists.txt for e.g) in a consumer application can locate the plugins.cfg file and make it available to the C++ application that loads this file ?

Aside of that: Challenges I face with testing plugin usage

Click to expand!

To test that the package information is correctly propagated by the package manager, we write test_package that consumes the packaged libraries. In this case I'm trying to consume the plugins and facing difficulties in finding a minimal example of how plugins are consumed in a simple application.

For e.g this is how my test application looks

#include <OGRE/OgreRoot.h>
#include <OGRE/OgrePlugin.h>
#include <OGRE/Plugins/BSPSceneManager/OgreBspSceneManager.h>
#include <iostream>

int main(int argc, char **argv) {
  std::string pluginsCfg{"/absolute/path/to/plugins.cfg"};
  std::cout << "plugins.cfg dir: " << pluginsCfg << "\n"; 
  Ogre::Root* mRoot = Ogre::Root::getSingletonPtr();
  try{

    mRoot->loadPlugin(pluginsCfg);
  }
  catch(Ogre::Exception& e){
    std::cout << e.what() << "\n";
  }
  return 0;
}

And this is how my plugins.cfg file look

# Defines plugins to load

# Define plugin folder
PluginFolder=/home/g.gulgulia/.conan/data/ogre/1.10.0/gg/ar-testing/package/86be16facb6eadc943efa25c42f14ee0f43c9377/lib/OGRE

# Define plugins

#Plugin=RenderSystem_GL
#Plugin=RenderSystem_GL3Plus
#Plugin=Plugin_ParticleFX
Plugin=Plugin_BSPSceneManager
# Plugin=Plugin_EXRCodec
#Plugin=Plugin_PCZSceneManager
#Plugin=Plugin_OctreeZone
#Plugin=Plugin_OctreeSceneManager

However when the test application runs, the line mRoot->loadPlugin(pluginsCfg) segfaults.

• is there a minimal example of testing ogre plugins since CCI doesn't allow very elaborate test packages.

[paroj]

How the build system (CMakeLists.txt for e.g) in a consumer application can locate the plugins.cfg file and make it available to the C++ application that loads this file ?

https://ogrecave.github.io/ogre/api/latest/setup.html#cmake

However when the test application runs, the line mRoot->loadPlugin(pluginsCfg) segfaults.

because mRoot == NULL. You must do new Ogre::Root("plugins.cfg").