Page 1 of 1

[2.2] Build issue/bug

Posted: Thu Oct 18, 2018 12:47 pm
by 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.

Re: [2.2] Build issue/bug

Posted: Thu Oct 18, 2018 4:11 pm
by rujialiu
al2950 wrote:
Thu Oct 18, 2018 12:47 pm
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? 8-)

Re: [2.2] Build issue/bug

Posted: Thu Oct 18, 2018 4:57 pm
by 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.

Re: [2.2] Build issue/bug

Posted: Fri Oct 19, 2018 10:05 am
by al2950
dark_sylinc wrote:
Thu Oct 18, 2018 4:57 pm
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.
dark_sylinc wrote:
Thu Oct 18, 2018 4:57 pm
CMake scripts need a serious overhaul. The main blockade against that is that it's a lot of work:
rujialiu wrote:
Thu Oct 18, 2018 4:11 pm
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!

Re: [2.2] Build issue/bug

Posted: Sat Oct 20, 2018 3:13 pm
by paroj
al2950 wrote:
Fri Oct 19, 2018 10:05 am
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.

Re: [2.2] Build issue/bug

Posted: Sat Oct 20, 2018 5:44 pm
by dark_sylinc
paroj wrote:
Sat Oct 20, 2018 3:13 pm
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:
    paroj wrote:
    Sat Oct 20, 2018 3:13 pm
    The thing is that supporting various install locations, OSX frameworks, windows PDB files and per-compiler workarounds *is* messy.
    This is sadly very true.

Re: [2.2] Build issue/bug

Posted: Sun Oct 21, 2018 6:54 am
by 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"

Re: [2.2] Build issue/bug

Posted: Sun Oct 21, 2018 7:00 am
by 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

Re: [2.2] Build issue/bug

Posted: Sun Oct 21, 2018 8:06 pm
by 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

Re: [2.2] Build issue/bug

Posted: Mon Oct 22, 2018 1:13 pm
by 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

Re: [2.2] Build issue/bug

Posted: Mon Oct 29, 2018 2:12 pm
by al2950
@dark_sylinc

Would you mind commenting on the above post please?

Re: [2.2] Build issue/bug

Posted: Mon Oct 29, 2018 4:02 pm
by dark_sylinc
al2950 wrote:
Mon Oct 22, 2018 1:13 pm
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?

Re: [2.2] Build issue/bug

Posted: Mon Oct 29, 2018 4:25 pm
by al2950
dark_sylinc wrote:
Mon Oct 29, 2018 4:02 pm
al2950 wrote:
Mon Oct 22, 2018 1:13 pm
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.

Re: [2.2] Build issue/bug

Posted: Mon Oct 29, 2018 5:11 pm
by dark_sylinc
al2950 wrote:
Mon Oct 29, 2018 4:25 pm
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 :lol:

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?

Re: [2.2] Build issue/bug

Posted: Mon Oct 29, 2018 11:49 pm
by al2950
dark_sylinc wrote:
Mon Oct 29, 2018 5:11 pm
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!