Ogre 2.0 internal includes

[phobossion]

Hey guys,

I just started contributing to Ogre 2.0 development by fixing some of the build scripts and I noticed a problem with the new codebase that I would like to solve next. However, since this is a subjective matter, I thought I'll ask the community first. The problem is:

Internal includes don't follow the standard scheme, i.e. #include "xxx" for headers from the local directory and #include <xxx> for other headers. This wouldn't be much of an issue if the include scheme would be the same for both internal and external use. In internal Ogre code, the root include directory is directly under include/, meaning that if I do #include "OgreConfig.h" anywhere in my code, it will build. However, if I use the same in code external to Ogre it will fail, because the headers are really under include/OGRE/. This is an issue that is preventing the user from using the library unless he manually adds /usr/local/include/OGRE/ into his include dirs for the given project (Linux example, is the same for Win, basically). This is really a non-standard situation that needs to be addressed.

My proposed solution is to add relative paths to these headers, i.e. instead of #include "OgreConfig.h" there would be #include "../../OgreConfig.h". I know that some books on coding standards prohibit relative paths in includes for various reasons, but it seems to me that it is a much cleaner solution than any alternative I can think of.

What do you guys think?

[dark_sylinc]

This is an issue that is preventing the user from using the library unless he manually adds /usr/local/include/OGRE/ into his include dirs for the given project (Linux example, is the same for Win, basically).

This is normally the way it works. I'm not familiar with "other" alternatives. Isn't adding header search paths for 3rd party libraries kind of standard procedure?
I guess what you're suggesting is that a Linux program should be capable of "#include <Ogre/Ogre.h" without having to set "/usr/local/include/OGRE/"?

[phobossion]

The problem is that it should be only necessary to include e.g. /usr/local/include or C:\dev\ogre\include into your project. You would then include files using #include <Ogre/OgreConfig.h> (which is the way it is designed to be and it is 100% valid). The problem now is that you need to add BOTH /usr/local/include AND /usr/local/include/OGRE to be able to use the new code.

[scrawl]

That is how it's always been (and for many other libraries too, not just Ogre).
There is no need to worry about it. CMake will take care of adding the include paths.

The problem is that it should be only necessary to include e.g. /usr/local/include

That wouldn't work anyway if the user chose to install Ogre to a non-standard location (e.g. for having multiple versions installed alongside each other).

You would then include files using #include <Ogre/OgreConfig.h>

This is not only longer and redundant (since you have "Ogre" twice in there), it's also not portable. Some distributions may choose to install Ogre includes e.g. to /usr/include/OGRE, or /usr/include/ogre or /usr/include/Ogre. It's a REAL problem and not just a speculation. I've seen this issue happen with OIS packages and as such includes like #include <OIS/OISFoobar.h> would no longer work.

Besides, I do not see how any of this is specific to Ogre 2.0.

[bstone]

This is not only longer and redundant (since you have "Ogre" twice in there)

The problem is that the redundant part really comes from OgreConfig.h ! I would have been a much happier man if I had #include <Ogre/Config.h> in my projects. Not to mention that navigating Ogre sources is annoying with that prefix and too much extra typing. As developers though, we'll always be facing the problems with include paths because every other library does that its own way, sigh.