[VS/Win] Snapshot 12.03.2016
-
- Gnome
- Posts: 379
- Joined: Fri Sep 16, 2011 4:54 pm
- x 10
-
- Halfling
- Posts: 50
- Joined: Tue Sep 18, 2012 3:30 am
- x 6
Re: [VS/Win] Snapshot 22.02.2014
A year since I last commented on this thread. And a year since I attempted to build Ogre 1_9 from source (I need to profile and mod the Ogre source to do what I need it to do, my game's current bottleneck is inside the old & dusty Ogre_1_8 binary libs that I am currently shackled with.)
I'm having a headache with cmake failing to recognise the FreeType dependants.
Using: Win8.1, MSVS2010, CMake2.8.12.2, Ogre_1_9-source (pulled from mercurial on 05-June-2014), and Transporter's dependency package "Dependencies-vc100-x86-22.02.2014.7z"
EDIT: Things I've already tried:
1.) Clicking 'Configure' over and over. - Didn't help.
2.) Using 'Add Entry' in CmakeGUI to add hard-coded path for 'FREETYPE_FT2BUILD_INCLUDE_DIR' - didn't help.
3.) Double checked Transporter's dependency package. It has FreeType251 in it. The makefiles reference FreeType251. I'm confused.
Here is my current CMake output: (it first says that it found it, then I get errors that it didn't find it?)
Any help would be appreciated.
Cheers,
Nick
I'm having a headache with cmake failing to recognise the FreeType dependants.
Using: Win8.1, MSVS2010, CMake2.8.12.2, Ogre_1_9-source (pulled from mercurial on 05-June-2014), and Transporter's dependency package "Dependencies-vc100-x86-22.02.2014.7z"
EDIT: Things I've already tried:
1.) Clicking 'Configure' over and over. - Didn't help.
2.) Using 'Add Entry' in CmakeGUI to add hard-coded path for 'FREETYPE_FT2BUILD_INCLUDE_DIR' - didn't help.
3.) Double checked Transporter's dependency package. It has FreeType251 in it. The makefiles reference FreeType251. I'm confused.
Here is my current CMake output: (it first says that it found it, then I get errors that it didn't find it?)
Code: Select all
Configuring OGRE 1.9.0
Search path: E:/projects/OGRE_1_9/Dependencies/include;E:/projects/OgreSDK_vc10_v1-9-0/Dependencies;E:/projects/OGRE_1_9/Dependencies;E:/projects/OgreSDK_vc10_v1-9-0/../Dependencies;E:/projects/OGRE_1_9/../Dependencies
Looking for ZLIB...
Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
Found ZLIB: optimized;E:/projects/OGRE_1_9/Dependencies/lib/Release/ZLib.lib;debug;E:/projects/OGRE_1_9/Dependencies/lib/Debug/ZLib.lib
Looking for ZZip...
Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
Found ZZip: optimized;E:/projects/OGRE_1_9/Dependencies/lib/Release/zziplib.lib;debug;E:/projects/OGRE_1_9/Dependencies/lib/Debug/zziplibd.lib
Looking for FreeImage...
Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
Found FreeImage: optimized;E:/projects/OGRE_1_9/Dependencies/lib/Release/FreeImageLib.lib;debug;E:/projects/OGRE_1_9/Dependencies/lib/Debug/FreeImageLib.lib
Looking for FREETYPE...
Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
CMAKE_PREFIX_PATH: E:/projects/OGRE_1_9/Dependencies/include;E:/projects/OgreSDK_vc10_v1-9-0/Dependencies;E:/projects/OGRE_1_9/Dependencies;E:/projects/OgreSDK_vc10_v1-9-0/../Dependencies;E:/projects/OGRE_1_9/../Dependencies
CMAKE_PREFIX_PATH: E:/projects/OGRE_1_9/Dependencies/include;E:/projects/OgreSDK_vc10_v1-9-0/Dependencies;E:/projects/OGRE_1_9/Dependencies;E:/projects/OgreSDK_vc10_v1-9-0/../Dependencies;E:/projects/OGRE_1_9/../Dependencies
Found FREETYPE: optimized;E:/projects/OGRE_1_9/Dependencies/lib/Release/freetype251.lib;debug;E:/projects/OGRE_1_9/Dependencies/lib/Debug/freetype251_D.lib
Looking for DirectX9...
Found DirectX9: C:/Program Files (x86)/Microsoft DirectX SDK (June 2010)/Lib/x86/d3d9.lib
Looking for DirectX11...
Found DirectX11: C:/Program Files (x86)/Microsoft DirectX SDK (June 2010)/Lib/x86/d3d11.lib
Looking for Cg...
Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
Found Cg: optimized;E:/projects/OGRE_1_9/Dependencies/lib/Release/cg.lib;debug;E:/projects/OGRE_1_9/Dependencies/lib/Debug/cg.lib
Looking for POCO...
Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
Could not locate POCO
Looking for TBB...
Could not locate TBB
Looking for GLSL_Optimizer...
Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
Found GLSL_Optimizer: optimized;E:/projects/OGRE_1_9/Dependencies/lib/Release/mesaglsl2.lib;debug;E:/projects/OGRE_1_9/Dependencies/lib/Debug/mesaglsl2.lib
Looking for HLSL2GLSL...
Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
Found HLSL2GLSL: optimized;E:/projects/OGRE_1_9/Dependencies/lib/Release/hlsl2glsl.lib;debug;E:/projects/OGRE_1_9/Dependencies/lib/Debug/hlsl2glsl.lib
Looking for OIS...
Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
Found OIS: optimized;E:/projects/OGRE_1_9/Dependencies/lib/Release/OIS.lib;debug;E:/projects/OGRE_1_9/Dependencies/lib/Debug/OIS_d.lib
Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
Looking for Softimage...
Could not locate Softimage
Could NOT find TinyXML (missing: TINYXML_INCLUDE_DIR TINYXML_LIBRARIES)
Looking for CppUnit...
Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
Could not locate CppUnit
-----------------------------------------------------------------------------
-- The following external packages were located on your system.
-- This installation will have the extra features provided by these packages.
+ zlib
+ zziplib
+ freeimage
+ freetype
+ OpenGL
+ OpenGL 3+
+ OpenGL ES 1.x
+ OpenGL ES 2.x
+ OpenGL ES 3.x
+ DirectX9
+ DirectX11
+ cg
+ boost
+ boost-thread
+ boost-date_time
+ GLSL Optimizer
+ HLSL2GLSL
+ OIS
-----------------------------------------------------------------------------
-- The following OPTIONAL packages could NOT be located on your system.
-- Consider installing them to enable more features from this software.
+ POCO: POCO framework <http://pocoproject.org/>
+ tbb: Threading Building Blocks <http://www.threadingbuildingblocks.org/>
+ Doxygen: Tool for building API documentation <http://doxygen.org>
+ Softimage: Softimage SDK needed for building XSIExporter <FALSE>
+ TinyXML: TinyXML needed for building OgreXMLConverter <FALSE>
+ CppUnit: Library for performing unit tests <http://cppunit.sourceforge.net>
-----------------------------------------------------------------------------
----------------------------------------------------------------------------
FEATURE SUMMARY
----------------------------------------------------------------------------
Building components:
+ Paging
+ Terrain
+ RTShader System
+ RTShader System Core Shaders
+ RTShader System Extensions Shaders
+ Volume
+ Overlay
Building plugins:
+ BSP scene manager
+ Cg program manager
+ Octree scene manager
+ Portal connected zone scene manager
+ Particle FX
Building rendersystems:
+ Direct3D 9
+ Direct3D 11
+ OpenGL
Building executables:
+ Samples
+ Tools
Building core features:
+ DDS image codec
+ FreeImage codec
+ ZIP archives
Build type: dynamic
Threading support: background (boost)
Use double precision: disabled
Assert mode: standard
Allocator type: nedmalloc (pooling)
STL containers use allocator: enabled
Strings use allocator: disabled
Memory tracker (debug): disabled
Memory tracker (release): disabled
Use Boost: enabled
----------------------------------------------------------------------------
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
FREETYPE_FT2BUILD_INCLUDE_DIR (ADVANCED)
used as include directory in directory E:/projects/OGRE_1_9/OgreMain
used as include directory in directory E:/projects/OGRE_1_9/RenderSystems/Direct3D9
used as include directory in directory E:/projects/OGRE_1_9/RenderSystems/Direct3D11
used as include directory in directory E:/projects/OGRE_1_9/RenderSystems/GL
used as include directory in directory E:/projects/OGRE_1_9/PlugIns/OctreeSceneManager
used as include directory in directory E:/projects/OGRE_1_9/PlugIns/BSPSceneManager
used as include directory in directory E:/projects/OGRE_1_9/PlugIns/CgProgramManager
used as include directory in directory E:/projects/OGRE_1_9/PlugIns/ParticleFX
used as include directory in directory E:/projects/OGRE_1_9/PlugIns/PCZSceneManager
used as include directory in directory E:/projects/OGRE_1_9/PlugIns/OctreeZone
used as include directory in directory E:/projects/OGRE_1_9/Components/Paging
used as include directory in directory E:/projects/OGRE_1_9/Components/Terrain
used as include directory in directory E:/projects/OGRE_1_9/Components/RTShaderSystem
used as include directory in directory E:/projects/OGRE_1_9/Components/Volume
used as include directory in directory E:/projects/OGRE_1_9/Components/Overlay
used as include directory in directory E:/projects/OGRE_1_9/Samples/BezierPatch
used as include directory in directory E:/projects/OGRE_1_9/Samples/CameraTrack
used as include directory in directory E:/projects/OGRE_1_9/Samples/Character
used as include directory in directory E:/projects/OGRE_1_9/Samples/Compositor
used as include directory in directory E:/projects/OGRE_1_9/Samples/DualQuaternion
used as include directory in directory E:/projects/OGRE_1_9/Samples/DynTex
used as include directory in directory E:/projects/OGRE_1_9/Samples/FacialAnimation
used as include directory in directory E:/projects/OGRE_1_9/Samples/Grass
used as include directory in directory E:/projects/OGRE_1_9/Samples/Instancing
used as include directory in directory E:/projects/OGRE_1_9/Samples/Lighting
used as include directory in directory E:/projects/OGRE_1_9/Samples/MeshLod
used as include directory in directory E:/projects/OGRE_1_9/Samples/NewInstancing
used as include directory in directory E:/projects/OGRE_1_9/Samples/OceanDemo
used as include directory in directory E:/projects/OGRE_1_9/Samples/ParticleFX
used as include directory in directory E:/projects/OGRE_1_9/Samples/PNTrianglesTessellation
used as include directory in directory E:/projects/OGRE_1_9/Samples/ShaderSystem
used as include directory in directory E:/projects/OGRE_1_9/Samples/ShaderSystemTexturedFog
used as include directory in directory E:/projects/OGRE_1_9/Samples/ShaderSystemMultiLight
used as include directory in directory E:/projects/OGRE_1_9/Samples/Shadows
used as include directory in directory E:/projects/OGRE_1_9/Samples/SkeletalAnimation
used as include directory in directory E:/projects/OGRE_1_9/Samples/SkyBox
used as include directory in directory E:/projects/OGRE_1_9/Samples/SkyDome
used as include directory in directory E:/projects/OGRE_1_9/Samples/SkyPlane
used as include directory in directory E:/projects/OGRE_1_9/Samples/Smoke
used as include directory in directory E:/projects/OGRE_1_9/Samples/SphereMapping
used as include directory in directory E:/projects/OGRE_1_9/Samples/Terrain
used as include directory in directory E:/projects/OGRE_1_9/Samples/EndlessWorld
used as include directory in directory E:/projects/OGRE_1_9/Samples/Tesselation
used as include directory in directory E:/projects/OGRE_1_9/Samples/TextureFX
used as include directory in directory E:/projects/OGRE_1_9/Samples/TextureArray
used as include directory in directory E:/projects/OGRE_1_9/Samples/Transparency
used as include directory in directory E:/projects/OGRE_1_9/Samples/VolumeTex
used as include directory in directory E:/projects/OGRE_1_9/Samples/VolumeCSG
used as include directory in directory E:/projects/OGRE_1_9/Samples/VolumeTerrain
used as include directory in directory E:/projects/OGRE_1_9/Samples/Water
used as include directory in directory E:/projects/OGRE_1_9/Samples/BSP
used as include directory in directory E:/projects/OGRE_1_9/Samples/CelShading
used as include directory in directory E:/projects/OGRE_1_9/Samples/DeferredShading
used as include directory in directory E:/projects/OGRE_1_9/Samples/CubeMapping
used as include directory in directory E:/projects/OGRE_1_9/Samples/Dot3Bump
used as include directory in directory E:/projects/OGRE_1_9/Samples/Fresnel
used as include directory in directory E:/projects/OGRE_1_9/Samples/Isosurf
used as include directory in directory E:/projects/OGRE_1_9/Samples/ParticleGS
used as include directory in directory E:/projects/OGRE_1_9/Samples/SSAO
used as include directory in directory E:/projects/OGRE_1_9/Samples/Browser
used as include directory in directory E:/projects/OGRE_1_9/Tools/XMLConverter
used as include directory in directory E:/projects/OGRE_1_9/Tools/MeshUpgrader
Configuring incomplete, errors occurred!
See also "E:/projects/OgreSDK_vc10_v1-9-0/CMakeFiles/CMakeOutput.log".
Cheers,
Nick
-
- Minaton
- Posts: 933
- Joined: Mon Mar 05, 2012 11:37 am
- Location: Germany
- x 110
Re: [VS/Win] Snapshot 24.05.2014
That's a strange problem. I set FREETYPE_FT2BUILD_INCLUDE_DIR to E:\dependencies\include\freetype and it's working. Btw, I've published new packages.
-
- Halfling
- Posts: 50
- Joined: Tue Sep 18, 2012 3:30 am
- x 6
Re: [VS/Win] Snapshot 24.05.2014
Cool, grabbed that.Transporter wrote:That's a strange problem. I set FREETYPE_FT2BUILD_INCLUDE_DIR to E:\dependencies\include\freetype and it's working. Btw, I've published new packages.
I think my problem was that I was clicking 'Add Entry' to hard-path the FREETYPE_FT2BUILD_INCLUDE_DIR value, and it was ignoring that, as the value technically already existed, only I couldn't see that it already existed until I clicked on the 'advanced' tick-box.
Thanks for the reply. And for the dependency packages! ;D
-
- Halfling
- Posts: 50
- Joined: Tue Sep 18, 2012 3:30 am
- x 6
Re: [VS/Win] Snapshot 24.05.2014
More fun with FreeType! ;D
The FindFreetype.cmake file I have references FreeType253, like so:
Your latest dependencies have FreeType253 in them.
But now that I have the CMake procedure working, the Ogre.SLN file that has been created has lots of link references to FreeType251.
Obviously, I can manually change these in the link settings for each project within VS. Is that the recomended thing to do, or is there something I can change in the makefiles so that the generated solution file will reference Freetype253 instead of FreeType251?
Thanks again in advance for any help/comments.
The FindFreetype.cmake file I have references FreeType253, like so:
Code: Select all
set(FREETYPE_LIBRARY_NAMES freetype253 freetype252 freetype251 freetype2501 freetype250 freetype2412 freetype2411 freetype2410 freetype249 freetype248 freetype246 freetype2311 freetype239 freetype238 freetype235 freetype219 freetype)
But now that I have the CMake procedure working, the Ogre.SLN file that has been created has lots of link references to FreeType251.
Obviously, I can manually change these in the link settings for each project within VS. Is that the recomended thing to do, or is there something I can change in the makefiles so that the generated solution file will reference Freetype253 instead of FreeType251?
Thanks again in advance for any help/comments.
-
- Minaton
- Posts: 933
- Joined: Mon Mar 05, 2012 11:37 am
- Location: Germany
- x 110
Re: [VS/Win] Snapshot 24.05.2014
You could change it manually in the overlay component project, but CMake will restore FreeType251 before you can start compiling. You have to change the freetype library settings in CMake and rerun configure and generate.Nickenstein79 wrote:But now that I have the CMake procedure working, the Ogre.SLN file that has been created has lots of link references to FreeType251.
Obviously, I can manually change these in the link settings for each project within VS. Is that the recomended thing to do, or is there something I can change in the makefiles so that the generated solution file will reference Freetype253 instead of FreeType251?
-
- Halfling
- Posts: 50
- Joined: Tue Sep 18, 2012 3:30 am
- x 6
Re: [VS/Win] Snapshot 24.05.2014
Ahh, yes. When I switched to your new dependency package this afternoon (with FreeType253 in it), the cmake setup was still refering to the FreeType251 that it detected yesterday.
I deleted the entire contents of the destination folder and restarted the whole Cmake procedure from scratch and now everything is pointing at the right things.
Thanks for the help, Transporter!
(PS: I still find it bizarre that cmake is finding FREETYPE_INCLUDE_DIR just fine, but consistently fails to find FREETYPE_FT2BUILD_INCLUDE_DIR. I wonder if the string "FREETYPE_FT2BUILD_INCLUDE_DIR" is generating a hash that clashes with another name somewhere in the system?)
I deleted the entire contents of the destination folder and restarted the whole Cmake procedure from scratch and now everything is pointing at the right things.
Thanks for the help, Transporter!
(PS: I still find it bizarre that cmake is finding FREETYPE_INCLUDE_DIR just fine, but consistently fails to find FREETYPE_FT2BUILD_INCLUDE_DIR. I wonder if the string "FREETYPE_FT2BUILD_INCLUDE_DIR" is generating a hash that clashes with another name somewhere in the system?)
-
- Halfling
- Posts: 50
- Joined: Tue Sep 18, 2012 3:30 am
- x 6
Re: [VS/Win] Snapshot 24.05.2014
YAY!
EDIT: Now trying to build the latest CEGUI version to match my newly working Ogre1_9 setup. Surprise surprise! The cmake for that is repeatedly failing to find boost. Lulz! ;D
(I JUST WANT TO WRITE SOME DAMN CODE FFS! Hehe!)
I wish I had decided to be an artist, or a plumber.
Code: Select all
2>------ Build started: Project: INSTALL, Configuration: Release Win32 ------
...
...
========== Build: 64 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
EDIT: Now trying to build the latest CEGUI version to match my newly working Ogre1_9 setup. Surprise surprise! The cmake for that is repeatedly failing to find boost. Lulz! ;D
(I JUST WANT TO WRITE SOME DAMN CODE FFS! Hehe!)
I wish I had decided to be an artist, or a plumber.
-
- Minaton
- Posts: 933
- Joined: Mon Mar 05, 2012 11:37 am
- Location: Germany
- x 110
Re: [VS/Win] Snapshot 24.05.2014
A long time ago I've built CEGUI for Ogre. I dropped CEGUI from my build process because you always have to change a few files to use Ogre with boost. I tried to submit a patch for that but ... I've switched to libRocket.Nickenstein79 wrote:Now trying to build the latest CEGUI version to match my newly working Ogre1_9 setup. Surprise surprise! The cmake for that is repeatedly failing to find boost. Lulz! ;D
(I JUST WANT TO WRITE SOME DAMN CODE FFS! Hehe!)
-
- Gremlin
- Posts: 183
- Joined: Sun May 01, 2005 2:00 pm
- x 23
Re: [VS/Win] Snapshot 24.05.2014
We use FindBoost that ships with cmake. You have 2 options Either you just pass the paths manually or you debug the cmake module and submit bug(s) to the cmake project.Nickenstein79 wrote:Now trying to build the latest CEGUI version to match my newly working Ogre1_9 setup. Surprise surprise! The cmake for that is repeatedly failing to find boost. Lulz! ;D
(I JUST WANT TO WRITE SOME DAMN CODE FFS! Hehe!)
Hi, your patch was a hack and broke the build for other users, that's why it was rejected. IIRC you deleted your entire repository halfway through the review process... I don't want people to get the impression that it's impossible to get patches into CEGUI. On the contrary, we are generally very happy to accept patches.Transporter wrote: A long time ago I've built CEGUI for Ogre. I dropped CEGUI from my build process because you always have to change a few files to use Ogre with boost. I tried to submit a patch for that but ... I've switched to libRocket.
-
- Minaton
- Posts: 933
- Joined: Mon Mar 05, 2012 11:37 am
- Location: Germany
- x 110
Re: [VS/Win] Snapshot 24.05.2014
I've deleted my repo because I stoped working with CEGUI - after the patches have been rejected and a few discussions on other submissions. Of course you can see accepted patches on bitbucket. The current dependency management is not an option for me, because I have to build multiple libraries multiple times. For example zlib is included in FreeImage for Ogre, included in FreeImage of cegui-dependencies and directly included in cegui-dependencies again (zziplib uses zlib from FreeImage at my computer). I like to build the libs only one time before compiling ogre! Yes, I've seen at FreeImage that you compile all libraries at once - which is still not an option. The Ogre/boost file needs modification, because it's out of date. If you use FindBoost from CMake why you don't use FindOgre from Ogre? boost detection is in there, also the current boost version require atomic as new dependency which is not in the CEGUI version.kulik wrote:Hi, your patch was a hack and broke the build for other users, that's why it was rejected. IIRC you deleted your entire repository halfway through the review process... I don't want people to get the impression that it's impossible to get patches into CEGUI. On the contrary, we are generally very happy to accept patches.
This thread is for my prebuild Ogre packages and not a discussion thread about CEGUI! There are a few reasons for me not to build and use CEGUI! I would like to stop this discussion here now. Thanks!
-
- Gremlin
- Posts: 183
- Joined: Sun May 01, 2005 2:00 pm
- x 23
Re: [VS/Win] Snapshot 24.05.2014
Heh, you ask questions and then say that you don't want he discussion. Just one last reply then.Transporter wrote:I like to build the libs only one time before compiling ogre! Yes, I've seen at FreeImage that you compile all libraries at once - which is still not an option. The Ogre/boost file needs modification, because it's out of date. If you use FindBoost from CMake why you don't use FindOgre from Ogre? boost detection is in there, also the current boost version require atomic as new dependency which is not in the CEGUI version.
This thread is for my prebuild Ogre packages and not a discussion thread about CEGUI! There are a few reasons for me not to build and use CEGUI! I would like to stop this discussion here now. Thanks!
1) You don't have to use cegui-dependencies package, it's provided for convenience only. It's not required. In fact on Linux nobody uses it because everybody can get deps from their distribution package manager. So yes, you can use the same libs you built for Ogre, it will work.
2) I am not sure why we don't use FindOgre from Ogre. I think it has to do with the fact that there was no such module when this was implemented. We now however have FindOgre from the sumwars project which deals with the boost dependency correctly.
3) We are not aware of the atomic dependency. Could you submit that as a bug with more details? Is it similar to the boost::system situation?
-
- Gremlin
- Posts: 155
- Joined: Thu Sep 17, 2009 8:43 pm
- Location: Austria
- x 9
Re: [VS/Win] Snapshot 24.05.2014
You can't be serious with that tone. There were legitimate reasons we could not accept the patch in that state and they were mentioned in the pull request. We would have gladly accepted your patch if you had made the changes that were REALLY required to be done to it. For whatever reason you decided not to make these really relevant changes.Transporter wrote:I've deleted my repo because I stoped working with CEGUI - after the patches have been rejected and a few discussions on other submissions.
There were two people reviewing your changes and they both came to the same result. Now, after looking at the bitbucket page, I havecome to this result as well. A lot of the modifications you suggested were good and had very good prospects, but others were right-out unusable because they were hacks and copy-pasting of lines, which would have caused numerous issues with CEGUI if not altered further. However, since you put all modifications into ONE single commit, it was not possible for us to pick the modifications selectively. This was described in the discussion on bitbucket as well: https://bitbucket.org/cegui/cegui/pull- ... s-for-ogre
I won't repeat every reason as to why we could not merge your pull request, but I assure you we did not do it because we dislike your or anyhting. We just cannot merge modifications that will cause issues in CEGUI. The way to go would have been to split your modifications into several commits, with each modification in a separate branch (simply by opening a branch with the commit) and then you can make a pull request for each of those branches using the bitbucket interface. Then we would have accepted some of those pull requests and suggested you to rework those that we cannot accept yet. You can still do this now The minimum for us to work with would have been to at least have those modifications split in several commits - then we could have cherry-picked them. This would of course not have been as optimal as having them in branches. The only other way for us to accept your pull request would have been for you to fix the WHOLE thing so we can accept everything - We can't just accept a complete mix of changes where some are beneficial and others break the CEGUI system entirely. What i just wrote is basically what Kulik (mpreisler) replied to you in his last reply before you erased your repository. I am not sure why you deleted it, actually.
I am sorry that you are disgruntled with the way the CEGUI library has to be built. We are always working on making the build-process better, however since we allow users to select and build their own dependencies, the CEGUI dependencies package we currently provide is for convenience of MAC OS X and Windows users. If you already built a certain dependency you can simply deselect them in the CMake GUI for the CEGUI dependencies, which takes a single click and therefore should be as convenient as possible. In that case they will not be built. If the CEGUI dependencies require dependencies you already use, you can as well configure them in CMAKe by providing the paths to the folders and files required. This is also a quite simple process. What would you suggest to make this easier? Or do you suggest this is an issue of lacking documentation?Transporter wrote: There are a few reasons for me not to build and use CEGUI! I would like to stop this discussion here now. Thanks!
PS: Regarding the boost libraries - I agree this needs to be solved better in CEGUI. However, Cmake has its own find-boost which apparently does not work very well on Windows at least. However, you can always define all paths manually in CMake, as described in my CEGUI Wiki article about building CEGUI for Ogre.
Edit: Changed wording and added info for clarity
Last edited by Ident on Fri Jun 06, 2014 2:43 pm, edited 1 time in total.
-
- Minaton
- Posts: 933
- Joined: Mon Mar 05, 2012 11:37 am
- Location: Germany
- x 110
Re: [VS/Win] Snapshot 24.05.2014
Damn! I don't want to post anything about CEGUI.
boost::system is from 1.50 and boost::atomic is from 1.54
cegui-dependencies was created for OSX and Windows. I'm building the libraries from source for Windows. For example freetype will creates an Freetype253.lib from the official source. Ogre's FindFreetype can find this library but the version of CEGUI could find only freetype2.lib or freetype.lib or libfreetype.lib. It's the same with other libraries.kulik wrote:1) You don't have to use cegui-dependencies package, it's provided for convenience only. It's not required. In fact on Linux nobody uses it because everybody can get deps from their distribution package manager. So yes, you can use the same libs you built for Ogre, it will work.
I don't know the reason, but all Ogre SDKs are distributing this script. Pointing CMake to a directory where it could find FindOGRE.cmake (OGRE_HOME/cmake) would solve the problem.kulik wrote:2) I am not sure why we don't use FindOgre from Ogre. I think it has to do with the fact that there was no such module when this was implemented. We now however have FindOgre from the sumwars project which deals with the boost dependency correctly.
Yes, it's similar to boost::system. Have a look at Dependencies.cmake:kulik wrote:3) We are not aware of the atomic dependency. Could you submit that as a bug with more details? Is it similar to the boost::system situation?
Code: Select all
# Find Boost
# Prefer static linking in all cases
if (WIN32 OR APPLE)
set(Boost_USE_STATIC_LIBS TRUE)
else ()
# Statically linking boost to a dynamic Ogre build doesn't work on Linux 64bit
set(Boost_USE_STATIC_LIBS ${OGRE_STATIC})
endif ()
if (APPLE AND OGRE_BUILD_PLATFORM_APPLE_IOS)
set(Boost_USE_MULTITHREADED OFF)
endif()
set(Boost_ADDITIONAL_VERSIONS "1.56" "1.56.0" "1.55" "1.55.0" "1.54" "1.54.0" "1.53" "1.53.0" "1.52" "1.52.0" "1.51" "1.51.0" "1.50" "1.50.0" "1.49" "1.49.0" "1.48" "1.48.0" "1.47" "1.47.0" "1.46" "1.46.0" "1.45" "1.45.0" "1.44" "1.44.0" "1.42" "1.42.0" "1.41.0" "1.41" "1.40.0" "1.40")
# Components that need linking (NB does not include header-only components like bind)
set(OGRE_BOOST_COMPONENTS thread date_time)
find_package(Boost COMPONENTS ${OGRE_BOOST_COMPONENTS} QUIET)
if (NOT Boost_FOUND)
# Try again with the other type of libs
if(Boost_USE_STATIC_LIBS)
set(Boost_USE_STATIC_LIBS OFF)
else()
set(Boost_USE_STATIC_LIBS ON)
endif()
find_package(Boost COMPONENTS ${OGRE_BOOST_COMPONENTS} QUIET)
endif()
if(Boost_FOUND AND Boost_VERSION GREATER 104900)
if(Boost_VERSION GREATER 105300)
set(OGRE_BOOST_COMPONENTS thread date_time system atomic chrono)
else()
set(OGRE_BOOST_COMPONENTS thread date_time system chrono)
endif()
find_package(Boost COMPONENTS ${OGRE_BOOST_COMPONENTS} QUIET)
endif()
if(Boost_VERSION GREATER 105200)
# Use boost threading version 4 for boost 1.53 and above
add_definitions( -DBOOST_THREAD_VERSION=4 )
endif()
if(Boost_FOUND AND NOT WIN32)
list(REMOVE_DUPLICATES Boost_LIBRARIES)
endif()
First, I don't need accepted patches - you could fix it by yourself. I only want a working solution in the end. A solution, I can use in my batch scripted build process. Second, I didn't know how to prevent bitbucket from merging all commits at that time.Ident wrote:A lot of the modifications you suggested were good and had very good prospects, but others were right-out unusable because they were hacks and copy-pasting of lines, which would have caused numerous issues with CEGUI if not altered further. However, since you put all modifications into ONE single commit, it was not possible for us to pick the modifications selectively.
-
- Gremlin
- Posts: 155
- Joined: Thu Sep 17, 2009 8:43 pm
- Location: Austria
- x 9
Re: [VS/Win] Snapshot 24.05.2014
Your tone now and in the replies to your pull request has often been presumptuous and you are keeping this up here right now although i came to clarify the situation and to help.Transporter wrote:First, I don't need accepted patches - you could fix it by yourself.
You do realise though that our work on CEGUI is unpaid and you did so far not provide anything useful to our community, dont you? because nevertheless you often talk as if you were in a position to make any demands from us as you now did by saying "I don't need that, i need you to fix it by yourself".
Here is another example:
You removed our API and ABI numbering system in your commits, without even understanding what it is used for or what consequences removing it could have and called it "stupid" because you thought it had an error in it. Errors can be fixed. You can suggest such a fix and we fix it, but you can't remove a whole feature you do not understand, just because you feel like it.Transporter wrote:there is a error in CMake with that stupid numbering system, that's the reason why I removed it.
There is no reason to use swear words and attitude. Especially not towards people who are doing all this hard work to make a free and open source library, and who do not get paid for it at all.
I am not aware of that bitbucket merges commits in pull requests. It never occured in any of my pull requests.Transporter wrote:Second, I didn't know how to prevent bitbucket from merging all commits at that time.
-
- Halfling
- Posts: 50
- Joined: Tue Sep 18, 2012 3:30 am
- x 6
Re: [VS/Win] Snapshot 24.05.2014
I've tried that more than a few times . I manually set "Boost_DIR" to the path of boost, hit configure and it changes back to 'Boost_DIR-NOTFOUND'. I'm currently working through what I assume is your tutorial (http://cegui.org.uk/wiki/Building_CEGUI ... reRenderer)kulik wrote: We use FindBoost that ships with cmake. You have 2 options Either you just pass the paths manually or you debug the cmake module and submit bug(s) to the cmake project.
But I can't get past step 8.
If I can't solve it I will start a topic over on your CEGUI forums, as this thread is about Transporter's Ogre-Dependencies.
-
- Gremlin
- Posts: 155
- Joined: Thu Sep 17, 2009 8:43 pm
- Location: Austria
- x 9
Re: [VS/Win] Snapshot 24.05.2014
I am the author of the wiki page you linked. I made this a while back because i realised some people have issues with getting this to work. Ogre uses boost only optionally. If you do not need it please build Ogre without boost and be done with it!Nickenstein79 wrote: I've tried that more than a few times . I manually set "Boost_DIR" to the path of boost, hit configure and it changes back to 'Boost_DIR-NOTFOUND'. I'm currently working through what I assume is your tutorial (http://cegui.org.uk/wiki/Building_CEGUI ... reRenderer)
But I can't get past step 8.
If you really think you need bost, then I will try to get it to work for you. First of all, BOOST_DIR isn't necessary for the configuration process. You need the path to the include directory and the paths to the boost system debug library and release library files respectively. Please edit the wiki page if you can improve it to make it more understandable.
-
- Halfling
- Posts: 50
- Joined: Tue Sep 18, 2012 3:30 am
- x 6
Re: [VS/Win] Snapshot 24.05.2014
Hi, Ident.
A quick question while you are here. Your guide mentions 'CEGUI_SAMPLES_USE_OGRE' but I'm not seeing this value in the cmake-gui, and I can't see a #define for it in the actual project (I'm getting a solution file now).
Is this a boolean value I should add myself and set it to true, or is this value no longer relevant to cmake?
EDIT: I'll continue this conversation on the CEGUI forums. We are dirtying up Transporters-Dependency thread with irrelevant discussions. It will just make things confusing for people looking for Ogre-Deps help in the future.
A quick question while you are here. Your guide mentions 'CEGUI_SAMPLES_USE_OGRE' but I'm not seeing this value in the cmake-gui, and I can't see a #define for it in the actual project (I'm getting a solution file now).
Is this a boolean value I should add myself and set it to true, or is this value no longer relevant to cmake?
EDIT: I'll continue this conversation on the CEGUI forums. We are dirtying up Transporters-Dependency thread with irrelevant discussions. It will just make things confusing for people looking for Ogre-Deps help in the future.
-
- Gremlin
- Posts: 155
- Joined: Thu Sep 17, 2009 8:43 pm
- Location: Austria
- x 9
Re: [VS/Win] Snapshot 24.05.2014
This value is no longer relevant, you just need to switch the samples & ogrerenderer now. Aalso, you never need to add any variables.Nickenstein79 wrote:Hi, Ident.
A quick question while you are here. Your guide mentions 'CEGUI_SAMPLES_USE_OGRE' but I'm not seeing this value in the cmake-gui, and I can't see a #define for it in the actual project (I'm getting a solution file now).
Is this a boolean value I should add myself and set it to true, or is this value no longer relevant to cmake?
-
- Halfling
- Posts: 50
- Joined: Tue Sep 18, 2012 3:30 am
- x 6
Re: [VS/Win] Snapshot 24.05.2014
Yep, I've got that sorted, cheers for the help, Ident.Ident wrote:This value is no longer relevant, you just need to switch the samples & ogrerenderer now. Aalso, you never need to add any variables.
My problem was that some of the directories that cmake detected were inside my 'CEGUI_0_8_SOURCE' folder, some inside my 'CEGUI_0_8_DEPENDENCIES_SOURCE' and some inside my 'CEGUI_0_8_DEPENDENCIES' folder. so it all went a bit screwy.
If I was to add anything to your build guide, it would be this: "WARNING: Double & Triple check all of the paths that Cmake thinks it has correctly found. Some of them might not be what you actually intended."
And thanks again, Transporter, Ogre-1-9 is now fully functional from source on my machine and my game is up and running again, with the bonus ability that I can now profile and debug-trace directly into Ogre source files!
(As a side note, my reason for wanting to profile and build Ogre from source, is to see if I can fix the micro-stutters that occur on adding new Mesh Entities to the scenegraph. Ogre's own Procedural landscape demos suffer horribly from this problem, as does my own game. My game procedurally generates a lot of landscape meshes as the camera moves (on an asynchronous boost thread, with the main thread adding finished Entities into the scenegraph during a FrameRenderingQueued callback). I'm not using Ogre's landscape system, but my game suffers from the same frame-stutter problem that the Ogre Landscape demos have.)
PS: You can see the frame stutters I'm talking about quite clearly in this vid I made last week (a quick wobbly-land experiment. My vert-shader is doing the wobble effect, I'm not rebuilding the mesh every frame. That would be insane.) -
[youtube]yzBTk9H41xM[/youtube]
(Switching to CEGUI forums for help now, as my current issue is that all of my game's GUI data is in the format for CEGUI_0.7.9 and I'm now linking against CEGUI_0.8.3. So the XML parser is exploding all over the place! I think they have a tool for converting between their xml data formats. So I'll be reading up on that tomorrow)
-
- Beholder
- Posts: 1512
- Joined: Fri Feb 22, 2013 4:44 am
- Location: Deep behind enemy lines
- x 139
Re: [VS/Win] Snapshot 24.05.2014
The reason for the stutter is that the renderer is stalled while you copy data into locked hardware buffers. More data = more waiting. The solution is to not move all your data in a single frame. Split it up somehow either by making the entities smaller and spreading out their loading over several frames, or fill the buffers for large entities incrementally over several frames.Nickenstein79 wrote:my reason for wanting to profile and build Ogre from source, is to see if I can fix the micro-stutters that occur on adding new Mesh Entities
Make a new thread for these discussions. This thread is derailed enough.
-
- Halfling
- Posts: 50
- Joined: Tue Sep 18, 2012 3:30 am
- x 6
Re: [VS/Win] Snapshot 24.05.2014
I wouldn't have spent the last three days tearing my entire game to shreds upgrading from ancient Ogre/CEGUI to the very latest available source versions without considering that. (I have the same issue if I distribute it by adding 100 verts per frame, or if I make the meshes a single upload of just 100 verts. (either via lock>memcpy>unlock OR buffer->writedata) The stutters occur on adding the finalized entity to the scenegraph. (SceneNodeAttach))c6burns wrote:Split it up somehow either by making the entities smaller and spreading out their loading over several frames
But, yeah... We are seriously derailing this thread now. I'll create a frame-stutter thread somewhere more appropriate.
-
- Gremlin
- Posts: 164
- Joined: Sun Apr 14, 2013 8:51 pm
- x 10
Re: [VS/Win] Snapshot 24.05.2014
Sorry, but Boost is still required to create OGRE applications?, i didn't see any post about this.
And Thanks to give precompiled binaries (Specially for OGRE 2.0)
And Thanks to give precompiled binaries (Specially for OGRE 2.0)
-
- Minaton
- Posts: 933
- Joined: Mon Mar 05, 2012 11:37 am
- Location: Germany
- x 110
Re: [VS/Win] Snapshot 24.05.2014
You welcome! Yes, boost is still required to build an ogre application. My builds are using boost for threading and there are some places where boost headers are included in ogre headers.hydexon wrote:Sorry, but Boost is still required to create OGRE applications?, i didn't see any post about this.
And Thanks to give precompiled binaries (Specially for OGRE 2.0)
I'm sorry for the delay of the 02.08.2014 build, but I moved to a new place and forgot to upload the files.
-
- Gremlin
- Posts: 164
- Joined: Sun Apr 14, 2013 8:51 pm
- x 10
Re: [VS/Win] Snapshot 02.08.2014
Don't worry just i needed clarification. i just downloaded Boost for my arch and compiler, thanks for the aclaration.Transporter wrote:You welcome! Yes, boost is still required to build an ogre application. My builds are using boost for threading and there are some places where boost headers are included in ogre headers.hydexon wrote:Sorry, but Boost is still required to create OGRE applications?, i didn't see any post about this.
And Thanks to give precompiled binaries (Specially for OGRE 2.0)
I'm sorry for the delay of the 02.08.2014 build, but I moved to a new place and forgot to upload the files.