[2.2] Build issue/bug

Design / architecture / roadmap discussions related to future of Ogre3D (version 2.0 and above)
Post Reply
al2950
OGRE Expert User
OGRE Expert User
Posts: 1131
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 51

[2.2] Build issue/bug

Post by al2950 » Thu Oct 18, 2018 12:47 pm

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.
0 x

rujialiu
Greenskin
Posts: 131
Joined: Mon May 09, 2016 8:21 am
x 9

Re: [2.2] Build issue/bug

Post by rujialiu » Thu Oct 18, 2018 4:11 pm

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-)
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 3770
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 131
Contact:

Re: [2.2] Build issue/bug

Post by dark_sylinc » 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.

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.
0 x

al2950
OGRE Expert User
OGRE Expert User
Posts: 1131
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 51

Re: [2.2] Build issue/bug

Post by al2950 » Fri Oct 19, 2018 10:05 am

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!
0 x

paroj
OGRE Team Member
OGRE Team Member
Posts: 615
Joined: Sun Mar 30, 2014 2:51 pm
x 85
Contact:

Re: [2.2] Build issue/bug

Post by paroj » Sat Oct 20, 2018 3:13 pm

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.
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 3770
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 131
Contact:

Re: [2.2] Build issue/bug

Post by dark_sylinc » Sat Oct 20, 2018 5:44 pm

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.
0 x

dermont
Orc Shaman
Posts: 768
Joined: Thu Dec 09, 2004 2:51 am
x 8

Re: [2.2] Build issue/bug

Post by dermont » Sun Oct 21, 2018 6:54 am

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"
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 3770
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 131
Contact:

Re: [2.2] Build issue/bug

Post by dark_sylinc » Sun Oct 21, 2018 7:00 am

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
0 x

al2950
OGRE Expert User
OGRE Expert User
Posts: 1131
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 51

Re: [2.2] Build issue/bug

Post by al2950 » Sun Oct 21, 2018 8:06 pm

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
0 x

al2950
OGRE Expert User
OGRE Expert User
Posts: 1131
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 51

Re: [2.2] Build issue/bug

Post by al2950 » Mon Oct 22, 2018 1:13 pm

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
0 x

al2950
OGRE Expert User
OGRE Expert User
Posts: 1131
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 51

Re: [2.2] Build issue/bug

Post by al2950 » Mon Oct 29, 2018 2:12 pm

@dark_sylinc

Would you mind commenting on the above post please?
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 3770
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 131
Contact:

Re: [2.2] Build issue/bug

Post by dark_sylinc » 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?
0 x

al2950
OGRE Expert User
OGRE Expert User
Posts: 1131
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 51

Re: [2.2] Build issue/bug

Post by al2950 » Mon Oct 29, 2018 4:25 pm

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.
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 3770
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 131
Contact:

Re: [2.2] Build issue/bug

Post by dark_sylinc » Mon Oct 29, 2018 5:11 pm

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?
0 x

al2950
OGRE Expert User
OGRE Expert User
Posts: 1131
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 51

Re: [2.2] Build issue/bug

Post by al2950 » Mon Oct 29, 2018 11:49 pm

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!
0 x

Post Reply