[2.2] Build issue/bug

[al2950]

Hi

In Ogre 2.2 the Hlms datablock headers have this line of code in them

Code: Select all

    #include "../../Common/include/OgreHlmsTextureBaseClass.h"

However when the Ogre Install project is run it places all headers, in the same path, breaking builds.

2.1 also has files in ../../Common/include/, but includes them like this

Code: Select all

#include "OgreHlmsBufferManager.h"

Could we please drop the "../../Common/include/" as its not needed and breaks SDK builds of Ogre.

[rujialiu]

Could we please drop the "../../Common/include/" as its not needed and breaks SDK builds of Ogre.

Haha, I agree. When I first tried to integrate Ogre 2.2 I told dark_sylinc and I replied "I hate CMake and please avoid using SDK builds" so I manually move these files around everytime I update Ogre 2.2. Can you make a PR?

[dark_sylinc]

Done.

Based on what you described, there's probably still the problem that the SDK installation folder structure should/must match exactly that of the source code.

CMake scripts need a serious overhaul. The main blockade against that is that it's a lot of work:

1. Multiple platforms: iOS, macOS, Linux, Windows (multiple SDK nightmare). There's also Android & Emscripten support (currently not in use)
2. There's a lot of edge cases our users expect to be handled which currently are (some of which I am probably not even aware they exist)

In an ideal world, user downloads the repo, creates the CMake, runs the build command and everything just works, with dependencies automatically handled (not in the way Ogre 1.x is handling them though... it breaks on some IDEs with CMake integration and it downloads ogredeps/rebuilds too many times unnecessarily) and an installed SDK makes no difference as linking from an in-source build.
Our current reality is very far from this ideal world.

[al2950]

Done.

Based on what you described, there's probably still the problem that the SDK installation folder structure should/must match exactly that of the source code.

Thanks. The output structure does not have to match, but I think its probably more logical if it did.

CMake scripts need a serious overhaul. The main blockade against that is that it's a lot of work:

Haha, I agree. When I first tried to integrate Ogre 2.2 I told dark_sylinc and I replied "I hate CMake and please avoid using SDK builds" so I manually move these files around everytime I update Ogre 2.2. Can you make a PR?

CMake is great, especially when you are trying to maintain a library over multiple platforms. However when it doesn't work it can cause a large amount of mental trauma! As dark_sylinc said, it needs a huge overhaul, my personal opinion is that is just too complex and messy in the way its current written. I think if we started from scratch it wouldn't be too hard, although a little time consuming. I certainly would not try and 'fix' the current cmake files...... Maybe I will add it to my list!

[paroj]

As dark_sylinc said, it needs a huge overhaul, my personal opinion is that is just too complex and messy in the way its current written. I think if we started from scratch it wouldn't be too hard, although a little time consuming. I certainly would not try and 'fix' the current cmake files...... Maybe I will add it to my list!

the sad truth is that it actually is just badly documented. I did an overhaul of it for 1.11 which also bumped the requirement to cmake 3.3. Although I could replace some of it by more modern cmake constructs, there was surprisingly little that could be removed.

The thing is that supporting various install locations, OSX frameworks, windows PDB files and per-compiler workarounds *is* messy.

[dark_sylinc]

the sad truth is that it actually is just badly documented. I did an overhaul of it for 1.11 which also bumped the requirement to cmake 3.3. Although I could replace some of it by more modern cmake constructs, there was surprisingly little that could be removed.

Our existing CMake codebase clutter can be attributed to 3 things:

1. We have code that workarounds CMake bugs that were fixed a decade ago (we were early adopters) or implement functionality CMake now provides out of the box with just one function call.
2. Lack of enforcing conventions and certain codepaths (i.e. there's only one way to build. Don't care about your favourite way to build. One way for all)
3. And last but not least:

   The thing is that supporting various install locations, OSX frameworks, windows PDB files and per-compiler workarounds *is* messy.

   This is sadly very true.

[dermont]

On Linux v2-2-WIP the Hlms Pbs headers are installed in a single folder. However in the *Cubemap.h headers:

Code: Select all

OgreParallaxCorrectedCubemap.h
#include "Cubemaps/OgreCubemapProbe.h"

OgreParallaxCorrectedCubemapAuto.h
#include "Cubemaps/OgreParallaxCorrectedCubemapBase.h"

OgreParallaxCorrectedCubemap.h
#include "Cubemaps/OgreParallaxCorrectedCubemapBase.h"

[dark_sylinc]

If anyone knows how to fix that (CMake not honoring the original path when installing) PRs are welcomed!

It appears here's the cause:
https://stackoverflow.com/questions/110 ... sing-cmake

[al2950]

I will probably finish integrating Ogre 2.2 this week, so the rest of these issues should be picked up, and ill create a PR

[al2950]

Right, most of these issues are relatively easy to solve. My only issues is the HLMS 'common' folder/files. They sit outside of any project structure, and are therefore not owned by a single project. Could I suggest that these files are added to OgreMain project? And potentially create a HLMS sub-directory in OgreMain to keep all HLMS stuff organised?

Happy to Create a PR if agreed

[al2950]

@dark_sylinc

Would you mind commenting on the above post please?

[dark_sylinc]

My only issues is the HLMS 'common' folder/files. They sit outside of any project structure, and are therefore not owned by a single project. Could I suggest that these files are added to OgreMain project?

I'm strongly inclined to no. What's the technical problem this is causing?

[al2950]

My only issues is the HLMS 'common' folder/files. They sit outside of any project structure, and are therefore not owned by a single project. Could I suggest that these files are added to OgreMain project?

I'm strongly inclined to no. What's the technical problem this is causing?

CMake installation scripts. Because they do not belong to a project, its not clear where they should be installed. Of course they can be duplicated, but thats what happens at the moment and it breaks the include paths.

So if are not happy about this the alternative is to ensure any code that includes files in common directory assumes they are in the same dir, or the dir is reference by the project includes. Then copy the common files used to the same directory is the library that uses them... Ill create a PR which will hopefully make it clearer.

[dark_sylinc]

CMake installation scripts. Because they do not belong to a project, its not clear where they should be installed. Of course they can be duplicated, but thats what happens at the moment and it breaks the include paths.

I'm not sure the concept of "keeping the same folder structure" is understood then

A CMake script from an app perspective should work after the following snippet:

Code: Select all

include_directories( "${OGRE_LOCATION}/Components/Hlms/Common/include" )
include_directories( "${OGRE_LOCATION}/Components/Hlms/Unlit/include" )
include_directories( "${OGRE_LOCATION}/Components/Hlms/Pbs/include" )

Am I missing something?

[al2950]

A CMake script from an app perspective should work after the following snippet:

Code: Select all

include_directories( "${OGRE_LOCATION}/Components/Hlms/Common/include" )
include_directories( "${OGRE_LOCATION}/Components/Hlms/Unlit/include" )
include_directories( "${OGRE_LOCATION}/Components/Hlms/Pbs/include" )

Yes that would be fine, however I feel it just creates another barrier for someone using a library. Ideally when you use an SDK you just want to simple add that SDK include directory. I can understand perhaps including optional components, but including a random directory a new comer does not understand, just seems ... sub-optimal!