System wide "plugins.cfg"

[andrecaldas]

Fellow Ogres,

I am really really new to Ogre. Please, forgive me in advance for anything silly I might say!

It seems to me that there are two different approaches when distributing software that uses OGRE:

1. distribute ogre all along; or

2. use a system provided ogre shared library

I am under the impression that, although Ogre can be installed system-wide, "Ogre::Root" class' constructor is not really designed to allow a system-wide "plugins.cfg".

[paroj]

see https://ogrecave.github.io/ogre/api/lat ... 72b00ce9f8

[andrecaldas]

see https://ogrecave.github.io/ogre/api/lat ... 72b00ce9f8

I am sorry and thank you, @paroj!!!
I see that I was wrong and, since Ogre::Root uses the Ogre::FileSystemLayer, it is in fact designed to be system-wide installation friendly.

But now I realize why my debian system does not find the default (installed by Ogre, not me) "plugins.cfg".
https://github.com/OGRECave/ogre-next/b ... er.cpp#L80

In linux systems, Ogre does some sort of ogre magic craft to determine the final executable directory.
But for system-wide shared libraries, the executable might be installed in a place completely different from the Ogre library. It actually could be not installed... running from my build dir, for example. Or it could be installed in my home directory, while the shared library is system-wide.

So, in *nixes, the curretn "getConfigPaths()" implementation does not return the "correct" paths ("correct" as in what I expected ).

IMO, a "correct" implementation for FileSystemLayer::getConfigPaths() would:

1. List build directories in debug mode.

2. List app installed directories. (the app needs to pass this information somewhere - or, the OS dependent ogre magic craft: /proc in nixes)

3. List Ogre installed directories: DATA_DIR.

4. Look into current working directory.

Also, I find this line a little curious:
https://github.com/OGRECave/ogre-next/b ... ayer.h#L99
Because the current directory was already searched for and the file is "known" to not exist. I guess that at least a warning message would be in place.

[paroj]

ah.. you are using ogre-next. That one is using the old config file resolution, which is indeed broken. ogre1 should work though.

[andrecaldas]

ah.. you are using ogre-next. That one is using the old config file resolution, which is indeed broken. ogre1 should work though.

Sorry! Forgot to mention that.

I see... probably it is this part:
https://github.com/OGRECave/ogre/blob/d ... #L117-L131

Code: Select all

        Dl_info info;
        if (dladdr((const void*)resolveSymlink, &info))
        {
            String base(info.dli_fname);
            // need to strip the module filename from the path
            String::size_type pos = base.rfind('/');
            if (pos != String::npos)
                base.erase(pos);


        String dirname = StringUtil::format("OGRE-%d.%d/", OGRE_VERSION_MAJOR, OGRE_VERSION_MINOR);
        // search inside ../share/OGRE-X.Y
        mConfigPaths.push_back(StringUtil::normalizeFilePath(base + "/../share/"+dirname, false));
        // then look relative to PIP structure
        mConfigPaths.push_back(StringUtil::normalizeFilePath(base+"/../../../../share/"+dirname));
    }

Shall I discuss this in the ogre-next forum?

[dark_sylinc]

OgreNext tries to search CFG files in system paths?!?!?!

In OgreNext I tend to recommend to shy away from system installation because there are several CMake settings to customize OgreNext build to break both API and ABI (though most of the time it is only ABI breakage).

If you're making a project that can be built from source code (e.g. FOSS projects), it's not impossible to use a system-wide installation; but it could significantly increase the testing burden to ensure it still renders fine using a different set of CMake settings from what the developer originally worked with.

[andrecaldas]

OgreNext tries to search CFG files in system paths?!?!?!

I don't know about windows or macs. In xnix systems, OgreV1 uses some magic to discover the "executable path" and then it searches relative to it. If the file is not found, it does some further magic to determine the "shared library path" and then it searches relative to it.

I find it too magic and I am not totally against it as a "last resort" and/or in "debug builds". There are recommendations Ogre could follow (it does sometimes) to make it portable, predictable and robust in what concerns path finding:
https://specifications.freedesktop.org/ ... ec/latest/

In OgreNext I tend to recommend to shy away from system installation because there are several CMake settings to customize OgreNext build to break both API and ABI (though most of the time it is only ABI breakage).

I really hope this sort of advice changes in a near future.
Of course, bundling everything together is a simple way to not have to worry about those type of issues. But being able to handle shared libraries is also a sign of a robust and good design/implementation.

If you're making a project that can be built from source code (e.g. FOSS projects), it's not impossible to use a system-wide installation; but it could significantly increase the testing burden to ensure it still renders fine using a different set of CMake settings from what the developer originally worked with.

I would love to do things in the "proper way"... whatever it means.
I believe lots of people have already thought about this "proper way" to handle API and ABI changes... the "proper way" to manage shared libraries... and I would like to learn and use it.

The same way, I would love to learn about the "proper way" to load resources in OgreV2. But it has been being a real struggle. I never know if the solution people present are "the proper way" or if is just the "hackish way" the author found to solve his/hers specific problem. For example, hard coding resource paths and bypassing resource management facilities.

[andrecaldas]

The same way, I would love to learn about the "proper way" to load resources in OgreV2. But it has been being a real struggle. I never know if the solution people present are "the proper way" or if is just the "hackish way" the author found to solve his/hers specific problem. For example, hard coding resource paths and bypassing resource management facilities.

An example:
viewtopic.php?t=97258

[sercero]

Fellow Ogres,

I am really really new to Ogre. Please, forgive me in advance for anything silly I might say!

It seems to me that there are two different approaches when distributing software that uses OGRE:

1. distribute ogre all along; or

2. use a system provided ogre shared library

I am under the impression that, although Ogre can be installed system-wide, "Ogre::Root" class' constructor is not really designed to allow a system-wide "plugins.cfg".

I think its better if you distribute OGRE along your app and use that library because a system wide OGRE installation is a recipe for trouble.

You'll have to check the system wide OGRE version and ask the user to update if it is below the version you tested against.

What if the system wide OGRE version is a newer version that your app supports? Should the user install an older version?

What happens if you ask the user to update OGRE and other OGRE dependent applications break?

I don't know if you are making a game or an app but OGRE is somewhat lightweight as a DLL.

In my opinion its not so bad to bundle it.

[paroj]

I think its better if you distribute OGRE along your app and use that library because a system wide OGRE installation is a recipe for trouble.

You'll have to check the system wide OGRE version and ask the user to update if it is below the version you tested against.

What if the system wide OGRE version is a newer version that your app supports? Should the user install an older version?

What happens if you ask the user to update OGRE and other OGRE dependent applications break?

I don't know if you are making a game or an app but OGRE is somewhat lightweight as a DLL.

In my opinion its not so bad to bundle it.

well, things are not that bad..

On Linux, Ogre DLLs are versioned like libOgreMain.so.14.2 and since Ogre 14, the Media files are versioned too. So you can easily have multiple versions of Ogre installed at the same time.

Also since Ogre 13, we provide ABI guarantees so all apps build against Ogre 14.2.0 will also work with Ogre 14.2.6. Also all app targeting Ogre 14.0, will compile with any Ogre 14.x release due to the API guarantees.

[sercero]

I think its better if you distribute OGRE along your app and use that library because a system wide OGRE installation is a recipe for trouble.

You'll have to check the system wide OGRE version and ask the user to update if it is below the version you tested against.

What if the system wide OGRE version is a newer version that your app supports? Should the user install an older version?

What happens if you ask the user to update OGRE and other OGRE dependent applications break?

I don't know if you are making a game or an app but OGRE is somewhat lightweight as a DLL.

In my opinion its not so bad to bundle it.

well, things are not that bad..

On Linux, Ogre DLLs are versioned like libOgreMain.so.14.2 and since Ogre 14, the Media files are versioned too. So you can easily have multiple versions of Ogre installed at the same time.

Also since Ogre 13, we provide ABI guarantees so all apps build against Ogre 14.2.0 will also work with Ogre 14.2.6. Also all app targeting Ogre 14.0, will compile with any Ogre 14.x release due to the API guarantees.

Oh, no.

I'm not disparagin OGRE

What I'm saying is that its easier for the developer to just bundle the version of OGRE that they tested their app with and be done with it.

Its not ideal, but for games it makes sense.

For an application perhaps not...