[Solved] Migrating files with ceed-migrate

[Ident]

I still have a Boost_DIR variable, instead of the Boost_INCLUDE_DIR you mention in the guide.

I m confused. I have both. Did you update to v0-8 branch as well? Did you clear the cmake cache?

[Nickenstein79]

Sorry, I mistyped there.

I meant to say that I'm not seeing a 'Boost_LIBRARY_DIR' variable like you have.

... However, on getting my boost_python_debug and release set correctly, and hitting configure, that variable has suddenly turned up as a new ungrouped entity that cmake managed to find by itself.

Screenshot attached:



EDIT: And on hitting configure again it has moved into the correct group.

So you might wan't to change that example of 'Boost_LIBRARY_DIR' in your guide, as that one doesn't actually exist/show-up in the list until _after_ the user has correctly pathd to at least one correct lib file. (That particular example could confuse someone in the future. It confused the hell out of me.)

[Nickenstein79]

SUCCESS! It all works!

Thank's COLOSSALLY for your help here, Ident! without your guide and your feedback I would have been utterly flummoxed!

A few things you could change in your guide:

1.) The thing I said in the previous post.
2.) You mention that peeps have to use msvc2008. I've just tried with msvc2010 and it does actually work (and probably newer versions?). Follow the instructions as they are for setting the cmake boost-paths, but also install the 'boost_1_55_0\lib32-msvc-10.0' libs and add that path to your 'additional linker directories' in msvs2010 for the 'PyCEGUI' and 'PyCEGUIOpenGLRenderer' builds. (and copy boost_python-vc100-mt-1_55.dll to your bin folder)
3.) Add a link in the guide for cloning the CEED mercurial repo. (otherwise people get to to the 'Open your CEED folder' bit, and think "What CEED folder?", like I did.)
4.) Remove this line "Type "python ceed-gui" and click enter, which should startup CEED". The runwrapper.bat file already does this bit.
5.) Move the 'Run CEED' section to the end of the guide, as people really should be doing the 'build PyCEGUI' and 'copy PyCEGUI dependencies' bits before running it.

[OPTIONAL]
6.) Add the following step to the guide: "After clicking 'build' for the PyCEGUI&PyCEGUIOpenGLRenderer projects, go and watch a movie or TWELVE, or go on holiday. It's going to take some time..."
[/OPTIONAL]


And once again:

A very HUGE thank you, Ident! <3


PS: If I get some spare time next weekend I will look into submitting a patch for the makefiles so that it works for msvc2010 without the need to manually add 'boost_1_55_0\lib32-msvc-10.0' into the linker settings in msvs. (and possibly for msvs2013 too, as I have the free express version of that already installed.)

[Ident]

1.) The thing I said in the previous post.
2.) You mention that peeps have to use msvc2008. I've just tried with msvc2010 and it does actually work (and probably newer versions?). Follow the instructions as they are for setting the cmake boost-paths, but also install the 'boost_1_55_0\lib32-msvc-10.0' libs and add that path to your 'additional linker directories' in msvs2010 for the 'PyCEGUI' and 'PyCEGUIOpenGLRenderer' builds. (and copy boost_python-vc100-mt-1_55.dll to your bin folder)
3.) Add a link in the guide for cloning the CEED mercurial repo. (otherwise people get to to the 'Open your CEED folder' bit, and think "What CEED folder?", like I did.)
4.) Remove this line "Type "python ceed-gui" and click enter, which should startup CEED". The runwrapper.bat file already does this bit.
5.) Move the 'Run CEED' section to the end of the guide, as people really should be doing the 'build PyCEGUI' and 'copy PyCEGUI dependencies' bits before running it.

[OPTIONAL]
6.) Add the following step to the guide: "After clicking 'build' for the PyCEGUI&PyCEGUIOpenGLRenderer projects, go and watch a movie or TWELVE, or go on holiday. It's going to take some time..."
[/OPTIONAL]

Please make these changes yourself. Please use your forum account for the wiki. It is easy and you can adjust whatever you want.

PS: If I get some spare time next weekend I will look into submitting a patch for the makefiles so that it works for msvc2010 without the need to manually add 'boost_1_55_0\lib32-msvc-10.0' into the linker settings in msvs. (and possibly for msvs2013 too, as I have the free express version of that already installed.)

Make a pull request please, it is easier for us to accept. A patch is of course fine too though.

[Nickenstein79]

Please make these changes yourself. Please use your forum account for the wiki. It is easy and you can adjust whatever you want.

Roger wilko, skipper.

Guide updated - http://cegui.org.uk/wiki/Building_CEED_for_Windows
Feel free to publicly bitch-slap me if I messed it all up.

Make a pull request please, it is easier for us to accept. A patch is of course fine too though.

Will do. If I have a few spare hours on Saturday I'll learn the makefile syntax.


EDIT: I've updated the guide again, adding a new section at the end to help people use their new CEED builds to migrate their old data (as that is why I started this thread to begin with.)

[Ident]

I love your changes, the article is so much more informative now.

The CEED migrate part should probably go somewhere else though. I will think about it.

[Nickenstein79]

I love your changes, the article is so much more informative now.

I'm glad you like it.

The CEED migrate part should probably go somewhere else though. I will think about it.

I agree. I added it there as a placeholder not knowing where else to put it. (but also because getting ceed-migrate to work with Kulik's recent bug-fix was what made me want to build ceed from scratch to begin with.)

Perhaps a better place for it might be in the 'datafiles' section of the porting-to-0_8 guide? (http://cegui.org.uk/wiki/Changes_and_Porting_Tips_for_0.8.0)

[Ident]

Best would be to make a new article for it, then link to it from both the porting guides, the ceed guide, and also the ceed build on windows guide

[Nickenstein79]

Best would be to make a new article for it, then link to it from both the porting guides, the ceed guide, and also the ceed build on windows guide

Good idea.

I've made those changes in the following articles:

http://cegui.org.uk/wiki/Changes_and_Porting_Tips_for_0.8.0
http://cegui.org.uk/wiki/CEED
http://cegui.org.uk/wiki/Building_CEED_for_Windows
http://cegui.org.uk/wiki/Using_CEED-Migrate

[Ident]

Good, thanks.

[Nickenstein79]

A heads up for Ident (and anyone else interested in building CEGUI/CEED/PyCEGUI/PyCEGUIOgreRenderer/PyCEGUIOpenGLRenderer from source on Windows):

At the weekend I wanted to clean my entire codebase and art-assets in such a way that I had everything in one place (rather than relying on dll & libs installed in disparate folders all over my HD, to make the process of full-project-backups much easier), but I also wanted to switch from MSVS2010 and test that absolutely everything worked using MSVS2012-Desktop-Express (as it is free). Using the very very latest of all available (stable) source code.

Good news. It does!

Rebuilding _everything_ from scratch using very latest boost (2.5.6), Python (2.7.7), Ogre (1.9), CEGUI/CEED(0.8.3) including rebuilding _all_ of CEGUIs dependencies, rebuilding _all_ Ogre's dependencies, via MSVS2012-Express _all_ work as per the instructions in our recently modified wiki articles.

AND AS A BONUS, I have discovered and resolved the find-boost issue when configuring CEGUI/PyCEGUI builds with CMake! (Yay!)

Basically, the following windows environment variables must be set before configuring with CMake: (This is why find-boost was failing. It refers to Windows-Environment-variables that didn't exist.)

'BOOST_INCLUDEDIR' (Where the boost *.hpp files are)
'BOOST_LIBRARYDIR' (Where the platform/compiler specific libs are)
'BOOST_ROOT' (Set this to the root folder which contains the above two folders.)

Once this is done, CMake will correctly find all of the correct boost libs when you click 'configure', so the manual folder/file pointing is no longer required. (Boost::System, Boost:DateAndTime, Boost::Python, Boost::Threads, etc...)

(I've updated our wiki guides to reflect this.)

[Ident]

Setting boost environment dirs is an option, yes, but consider having multiple projects using boost and they are using multiple versions of boost. therefore i always mentioned setting the paths manually in cmake in the guides, it is pretty much proof of not messing with other configurations.

[Nickenstein79]

Setting boost environment dirs is an option, yes, but consider having multiple projects using boost and they are using multiple versions of boost. therefore i always mentioned setting the paths manually in cmake in the guides, it is pretty much proof of not messing with other configurations.

But that really should not be an issue, ever.

The boost distributions are set in such a way that 'headers' and things which don't need an external binary are in one place, and all platform specific binaries live within a subfolder demarcated as such.

Yes, people may want to have multiply projects using multiple boost versions, but if they are working from source, the best option is to upgrade everything simultaneously.

The issue I have seen recur is people getting very confused when cmake fails. With this new instruction, cmake will succeed. I don't think I have seen an issue where people where trying to merge projects using conflicting boost-distros. So it's probably a good rule-of-thumb to use one, and set an environment variable.

[Ident]

I don't understand what you mean. My point is that you can have boost version 1.0 and boost version 2.0 installed and use them each in different projects and for some reason you might not want to use the 1.0 version in the other project. Since the boost env variables are the same for both projects they would access the same folder so this would not allow the user to choose the boost version they wanted for the project they wanted to use it.
Either way, I added a notification in the wiki article saying that using env. variables is optional

[Nickenstein79]

The point I am making, is that CMake IS reading those environment variables, and we have in no-way EVER explained to users why that cmake find-boost error exists.

Now they have an explanation, and a clear way to resolve the issue. There is nothing stopping them from changing that environment variable when they switch projects. (That's why it's a called a variable.)


EDIT: Anyone attempting to build PyCEGUI as a dependency of a CEED-Source-re-Build is (hopefully) accurately aware of windows-environment-variables and their effects.