I see this branch has some commits, that could be applied already on trunk without distrupting the compile-ability of trunk, like r7698 "removed linux-static directory". Would it be okay to cherry pick those already or do you want to keep them as it is and merge afterwards?Geoff the Medio wrote:I'm mixing in a simultaneous update of various other dependencies, as the boost update has gotten complicated.
Should SDL be used as the GUI instead of Ogre?
Moderator: Committer
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
Re: Should SDL be used as the GUI instead of Ogre?
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Should SDL be used as the GUI instead of Ogre?
No preference... Linux static in particular hasn't had any attention in long enough that I think it's safe to remove.adrian_broher wrote:Would it be okay to cherry pick those already or do you want to keep them as it is and merge afterwards?
Re: Should SDL be used as the GUI instead of Ogre?
I finally managed to compile this branch on my linux box. I ran into some issues.
First, many files that have been removed had not been erased from CMakeLists. The patch below removes all references that gave file missing errors.
The branch failed to compile against the current default version of boost in ubuntu (1.54), even when I added BOOST_SPIRIT_USE_PHOENIX_V3 to make spirit use the same version of phoenix 1.56 uses. It is not inconceivable it could be made to work, but I decided to try boost 1.56 instead.
The stable 1.56 serialization has a bug, which apparently is fixed in development. I fixed it manually as described here https://chaste.cs.ox.ac.uk/trac/ticket/2585. Then it eventually worked. To use a custom boost you need to set the environment variable BOOST_ROOT when running cmake. I also added a -DBoost_NO_BOOST_CMAKE=TRUE, but am not sure that was necessary.
There were some issues with glew and opengl definitions. I resolved them by applying the vbo adventure patch, since adrian made them behave so nicely there.
The Logger was also included with a wrong path from one file. There is a trivial patch below for that, too.
There is also patch that removes SerializePathingEngine, since pathing engine itself seems to be gone.
First, many files that have been removed had not been erased from CMakeLists. The patch below removes all references that gave file missing errors.
The branch failed to compile against the current default version of boost in ubuntu (1.54), even when I added BOOST_SPIRIT_USE_PHOENIX_V3 to make spirit use the same version of phoenix 1.56 uses. It is not inconceivable it could be made to work, but I decided to try boost 1.56 instead.
The stable 1.56 serialization has a bug, which apparently is fixed in development. I fixed it manually as described here https://chaste.cs.ox.ac.uk/trac/ticket/2585. Then it eventually worked. To use a custom boost you need to set the environment variable BOOST_ROOT when running cmake. I also added a -DBoost_NO_BOOST_CMAKE=TRUE, but am not sure that was necessary.
There were some issues with glew and opengl definitions. I resolved them by applying the vbo adventure patch, since adrian made them behave so nicely there.
The Logger was also included with a wrong path from one file. There is a trivial patch below for that, too.
There is also patch that removes SerializePathingEngine, since pathing engine itself seems to be gone.
- Attachments
-
[The extension patch has been deactivated and can no longer be displayed.]
-
[The extension patch has been deactivated and can no longer be displayed.]
-
[The extension patch has been deactivated and can no longer be displayed.]
Any code by me in this post is released under GPL 2.0 or later.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Should SDL be used as the GUI instead of Ogre?
If "stable" boost 1.56 can't compile without building a patched version from source, it can't be the required / expected version for FreeOrion. I think Boost 1.55 has Phoenix 3... and I'm not sure why you'd even need Phoenix 3, as most of the changes required for it were within boost version check preprocessor if clauses... So what were the problems with Boost 1.54?Mitten.O wrote:...I decided to try boost 1.56 instead.
The stable 1.56 serialization has a bug, which apparently is fixed in development. I fixed it manually as described here https://chaste.cs.ox.ac.uk/trac/ticket/2585. Then it eventually worked. To use a custom boost you need to set the environment variable BOOST_ROOT when running cmake.
Re: Should SDL be used as the GUI instead of Ogre?
Well the error messages are over 3000 lines long, but the first one is
parse/ReportParseError.h:19:50: error: ‘boost::spirit::info::nil_’ has not been declared
void operator()(boost::spirit::info::nil_) const;
Many redefinition errors like this:
parse/AlignmentsParser.cpp:7:
/usr/include/boost/phoenix/core/is_actor.hpp:41:12: error: redefinition of ‘struct boost::phoenix::is_actor<boost::phoenix::actor<BaseT0> >’
struct is_actor<actor<Expr> >
Missing things also:
parse/AlignmentsParser.cpp:1:
/usr/include/boost/spirit/home/phoenix/core/actor.hpp: In instantiation of ‘struct boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::argument<3> >, 0l> >’:
/usr/include/boost/phoenix/core/preprocessed/argument_predefined_10.hpp:13:147: required from here
/usr/include/boost/spirit/home/phoenix/core/actor.hpp:92:9: error: no type named ‘no_nullary’ in ‘struct boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::argument<3> >, 0l>’
nullary_result;
Also like this:
parse/AlignmentsParser.cpp:7:
/usr/include/boost/phoenix/core/detail/preprocessed/function_eval_10.hpp:7:1574: error: wrong number of template arguments (7, should be 5)
namespace boost { namespace phoenix { namespace detail { namespace tag { struct function_eval {}; template <typename Ostream> inline Ostream &operator<<( Ostream & os , function_eval) { os << "function_eval"; return os; } } namespace expression { template < typename A0 = void , typename A1 = void , typename A2 = void , typename A3 = void , typename A4 = void , typename A5 = void , typename A6 = void , typename A7 = void , typename A8 = void , typename A9 = void , typename Dummy = void > struct function_eval; template < typename A0 , typename A1 > struct function_eval< A0 , A1 > : boost::phoenix::expr< tag:: function_eval , A0 , A1 > {}; template < typename A0 , typename A1 , typename A2 > struct function_eval< A0 , A1 , A2 > : boost::phoenix::expr< tag:: function_eval , A0 , A1 , A2 > {}; template < typename A0 , typename A1 , typename A2 , typename A3 > struct function_eval< A0 , A1 , A2 , A3 > : boost::phoenix::expr< tag:: function_eval , A0 , A1 , A2 , A3 > {}; template < typename A0 , typename A1 , typename A2 , typename A3 , typename A4 > struct function_eval< A0 , A1 , A2 , A3 , A4 > : boost::phoenix::expr< tag:: function_eval , A0 , A1 , A2 , A3 , A4 > {}; template < typename A0 , typename A1 , typename A2 , typename A3 , typename A4 , typename A5 > struct function_eval< A0 , A1 , A2 , A3 , A4 , A5 > : boost::phoenix::expr< tag:: function_eval , A0 , A1 , A2 , A3 , A4 , A5 > {}; template < typename A0 , typename A1 , typename A2 , typename A3 , typename A4 , typename A5 , typename A6 > struct function_eval< A0 , A1 , A2 , A3 , A4 , A5 , A6 > : boost::phoenix::expr< tag:: function_eval , A0 , A1 , A2 , A3 , A4 , A5 , A6 > {}; template < typename A0 , typename A1 , typename A2 , typename A3 , typename A4 , typename A5 , typename A6 , typename A7 > struct function_eval< A0 , A1 , A2 , A3 , A4 , A5 , A6 , A7 > : boost::phoenix::expr< tag:: function_eval , A0 , A1 , A2 , A3 , A4 , A5 , A6 , A7 > {}; template < typename A0 , typename A1 , typename A2 , typename A3 , typename A4 , typename A5 , typename A6 , typename A7 , typename A8 > struct function_eval< A0 , A1 , A2 , A3 , A4 , A5 , A6 , A7 , A8 > : boost::phoenix::expr< tag:: function_eval , A0 , A1 , A2 , A3 , A4 , A5 , A6 , A7 , A8 > {}; template < typename A0 , typename A1 , typename A2 , typename A3 , typename A4 , typename A5 , typename A6 , typename A7 , typename A8 , typename A9 > struct function_eval< A0 , A1 , A2 , A3 , A4 , A5 , A6 , A7 , A8 , A9 > : boost::phoenix::expr< tag:: function_eval , A0 , A1 , A2 , A3 , A4 , A5 , A6 , A7 , A8 , A9 > {}; typedef proto::functional::make_expr< tag:: function_eval > make_function_eval; } namespace rule { struct function_eval : expression:: function_eval < meta_grammar , proto::vararg< meta_grammar > > {}; } } } } namespace boost { namespace phoenix { template <typename Dummy> struct meta_grammar::case_< :: boost :: phoenix :: detail :: tag:: function_eval , Dummy > : enable_rule< :: boost :: phoenix :: detail :: rule:: function_eval , Dummy > {}; } }
parse/ReportParseError.h:19:50: error: ‘boost::spirit::info::nil_’ has not been declared
void operator()(boost::spirit::info::nil_) const;
Many redefinition errors like this:
parse/AlignmentsParser.cpp:7:
/usr/include/boost/phoenix/core/is_actor.hpp:41:12: error: redefinition of ‘struct boost::phoenix::is_actor<boost::phoenix::actor<BaseT0> >’
struct is_actor<actor<Expr> >
Missing things also:
parse/AlignmentsParser.cpp:1:
/usr/include/boost/spirit/home/phoenix/core/actor.hpp: In instantiation of ‘struct boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::argument<3> >, 0l> >’:
/usr/include/boost/phoenix/core/preprocessed/argument_predefined_10.hpp:13:147: required from here
/usr/include/boost/spirit/home/phoenix/core/actor.hpp:92:9: error: no type named ‘no_nullary’ in ‘struct boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::argument<3> >, 0l>’
nullary_result;
Also like this:
parse/AlignmentsParser.cpp:7:
/usr/include/boost/phoenix/core/detail/preprocessed/function_eval_10.hpp:7:1574: error: wrong number of template arguments (7, should be 5)
namespace boost { namespace phoenix { namespace detail { namespace tag { struct function_eval {}; template <typename Ostream> inline Ostream &operator<<( Ostream & os , function_eval) { os << "function_eval"; return os; } } namespace expression { template < typename A0 = void , typename A1 = void , typename A2 = void , typename A3 = void , typename A4 = void , typename A5 = void , typename A6 = void , typename A7 = void , typename A8 = void , typename A9 = void , typename Dummy = void > struct function_eval; template < typename A0 , typename A1 > struct function_eval< A0 , A1 > : boost::phoenix::expr< tag:: function_eval , A0 , A1 > {}; template < typename A0 , typename A1 , typename A2 > struct function_eval< A0 , A1 , A2 > : boost::phoenix::expr< tag:: function_eval , A0 , A1 , A2 > {}; template < typename A0 , typename A1 , typename A2 , typename A3 > struct function_eval< A0 , A1 , A2 , A3 > : boost::phoenix::expr< tag:: function_eval , A0 , A1 , A2 , A3 > {}; template < typename A0 , typename A1 , typename A2 , typename A3 , typename A4 > struct function_eval< A0 , A1 , A2 , A3 , A4 > : boost::phoenix::expr< tag:: function_eval , A0 , A1 , A2 , A3 , A4 > {}; template < typename A0 , typename A1 , typename A2 , typename A3 , typename A4 , typename A5 > struct function_eval< A0 , A1 , A2 , A3 , A4 , A5 > : boost::phoenix::expr< tag:: function_eval , A0 , A1 , A2 , A3 , A4 , A5 > {}; template < typename A0 , typename A1 , typename A2 , typename A3 , typename A4 , typename A5 , typename A6 > struct function_eval< A0 , A1 , A2 , A3 , A4 , A5 , A6 > : boost::phoenix::expr< tag:: function_eval , A0 , A1 , A2 , A3 , A4 , A5 , A6 > {}; template < typename A0 , typename A1 , typename A2 , typename A3 , typename A4 , typename A5 , typename A6 , typename A7 > struct function_eval< A0 , A1 , A2 , A3 , A4 , A5 , A6 , A7 > : boost::phoenix::expr< tag:: function_eval , A0 , A1 , A2 , A3 , A4 , A5 , A6 , A7 > {}; template < typename A0 , typename A1 , typename A2 , typename A3 , typename A4 , typename A5 , typename A6 , typename A7 , typename A8 > struct function_eval< A0 , A1 , A2 , A3 , A4 , A5 , A6 , A7 , A8 > : boost::phoenix::expr< tag:: function_eval , A0 , A1 , A2 , A3 , A4 , A5 , A6 , A7 , A8 > {}; template < typename A0 , typename A1 , typename A2 , typename A3 , typename A4 , typename A5 , typename A6 , typename A7 , typename A8 , typename A9 > struct function_eval< A0 , A1 , A2 , A3 , A4 , A5 , A6 , A7 , A8 , A9 > : boost::phoenix::expr< tag:: function_eval , A0 , A1 , A2 , A3 , A4 , A5 , A6 , A7 , A8 , A9 > {}; typedef proto::functional::make_expr< tag:: function_eval > make_function_eval; } namespace rule { struct function_eval : expression:: function_eval < meta_grammar , proto::vararg< meta_grammar > > {}; } } } } namespace boost { namespace phoenix { template <typename Dummy> struct meta_grammar::case_< :: boost :: phoenix :: detail :: tag:: function_eval , Dummy > : enable_rule< :: boost :: phoenix :: detail :: rule:: function_eval , Dummy > {}; } }
Any code by me in this post is released under GPL 2.0 or later.
Re: Should SDL be used as the GUI instead of Ogre?
Same here on OSX, with emphasis on finally - that surely was some hard work. I ran into most of the issues you encountered (unfortunately before you posted here, that would have saved me a lot of time and headache), and some more (mostly OSX specific):Mitten.O wrote:I finally managed to compile this branch on my linux box. I ran into some issues.
Yep, that has been a nasty one. This one alone took me several hours to figure out, the build errors the compiler drowned me in weren't any help at all, at least for me Finally found the same link you posted, so on OSX too boost 1.56 only works with this patch.The stable 1.56 serialization has a bug, which apparently is fixed in development. I fixed it manually as described here https://chaste.cs.ox.ac.uk/trac/ticket/2585.
Same here, although I solved them by replacingThere were some issues with glew and opengl definitions.
Code: Select all
#include <GL/glew.h>
Code: Select all
#ifdef __MACOSX__
#include <SDL2/SDL_opengl.h>
#include <OpenGL/glu.h>
#else
#include <GL/glew.h>
#endif
ShaderProgram.cpp. Fortunately, that one was easy.The Logger was also included with a wrong path from one file.
That actually caused build errors on OSX, so I had to remove SerializePathingEngine.There is also patch that removes SerializePathingEngine, since pathing engine itself seems to be gone.
Additional issues I ran into:
chmain.h has been removed, which caused build errors on OSX. @Geoff: Please restore chmain.h, it's needed by the OSX specific chmain.mm and GUIController.mm (former OgreController.mm).
What caused by far the most headache for me and took the most time to figure out was another bug in boost 1.56 that causes the boost build system to look for the OSX SDKs in the wrong location on OSX 10.9 with Xcode 5. I think that normally that would give you some meaningful error messages when trying to build boost. My system however has been upgraded from 10.6 and this specific setup resulted in a successful build of boost, but which was somehow mangled, as it produced a lot of obscure link errors when I tried to build FO. It has been luck more than anything else that I found out what was wrong and how to fix it.
Upgrading boost really is a major PITA...
Well, finally I've been able to build FO with the SDL branch and boost 1.56, although I had to solve some more issues before I got a build that didn't crash. But I have to say the results are worth all the trouble. With SDL the mouse pointer isn't locked into the FO window anymore, I can resize the window like any other, no need to do that by changing the options, even the standard OSX fullscreen feature works flawlessly.
One issue was that the FO app didn't completely quit when I exited the game. The FO window was closed, but the app itself didn't quit. Have been able to fix that by adding a line to GUIController.mm, but apparently GG-SDL does something different than GG-Ogre when exiting.
Finally, there is an issue I wasn't able to solve: when launching FO, the FO window is resized to a small window in the top left corner of the screen. You always have to resize the window to the desired size manually before you can play. That's of course somewhat annoying...
Re: Should SDL be used as the GUI instead of Ogre?
Oh no... after I finally got the entire thing working? If we don't upgrade to 1.56, can't we stay with 1.51? At least that version has been working so far...Geoff the Medio wrote:If "stable" boost 1.56 can't compile without building a patched version from source, it can't be the required / expected version for FreeOrion.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Should SDL be used as the GUI instead of Ogre?
No, but 1.55 is an option. I think it also uses (or at least has) Phoenix 3, so it should avoid most of the above issues...Vezzra wrote:...can't we stay with 1.51?
Feel free to add it back yourself if I haven't...Vezzra wrote:Please restore chmain.h
Edit: Also, please make sure you're building Boost with zlib support in iostreams. This will be necessary to be able to use compressed text/xml based serialization.
Re: Should SDL be used as the GUI instead of Ogre?
I've tried building FO with boost 1.55, the only setup that worked was trunk without BOOST_SPIRIT_USE_PHOENIX_V3. This one however worked right out of the box. Just dropped the 1.55 includes and binary libs into their respective locations in the dependencies folder, build and run. No issues, no adjustments necessery, nothing. Just workedGeoff the Medio wrote:No, but 1.55 is an option. I think it also uses (or at least has) Phoenix 3, so it should avoid most of the above issues
Everything else failed however. Building trunk with BOOST_SPIRIT_USE_PHOENIX_V3 failed (no surprise here), but also building the SDL branch, with or without BOOST_SPIRIT_USE_PHOENIX_V3. Building the SDL branch only works with boost 1.56.
(I wanted to attach the build logs of the failed builds, but I get a "Sorry, the board attachment quota has been reached." message.)
How do I do that?Also, please make sure you're building Boost with zlib support in iostreams. This will be necessary to be able to use compressed text/xml based serialization.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Should SDL be used as the GUI instead of Ogre?
The attachment quota has been increased, so please indicate how the SDL branch fails with 1.55. If it's just the nil_ thing, remove the _ from the few places I added it to support 1.56, such as in ReportParseError.h,Vezzra wrote:Building the SDL branch only works with boost 1.56.
Code: Select all
void operator()(boost::spirit::info::nil_) const;
Code: Select all
#if BOOST_VERSION < 105600
template <typename Arg1, typename Arg2> // Phoenix v2
struct result
{ typedef void type; };
#else
typedef void result_type;
#endif
Make sure you have the zlib source available. I think I then had to add some environment variables (in a batch file, so you could probly use a shell script or do it manually) to point to that so the boost build system could see it. There should be some indications while running b2 (boost jam version 2?) to build boost that it has found and is using zlib. It's probably also possible to add something to project-config.jam, as I had to do to get it to build boost python, to point to the python source directory.Vezzra wrote:How do I do that?
Re: Should SDL be used as the GUI instead of Ogre?
After I removed the _ from all nil_ occurrences and changed the boost version to 105500 in all occurrences of the preprocessor defines for the result type stuff FO built and ran successfully (with BOOST_SPIRIT_USE_PHOENIX_V3 enabled). Hooray! (Shall I commit these changes?)
The zlib stuff also seems to work, at least I got some indicators like "zlib: yes" on the output of the boost build process. However, I noticed that boosts iostreams library hasn't been used for FO, at least on OSX. Assuming that it will be needed if we want to make use of the zlib support, I've included iostreams now and linked it to Common, the server, the human and the AI client. That's probably overkill...?
The zlib stuff also seems to work, at least I got some indicators like "zlib: yes" on the output of the boost build process. However, I noticed that boosts iostreams library hasn't been used for FO, at least on OSX. Assuming that it will be needed if we want to make use of the zlib support, I've included iostreams now and linked it to Common, the server, the human and the AI client. That's probably overkill...?
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Should SDL be used as the GUI instead of Ogre?
That will break on 1.56 or later, so it should be put into a boost version #if check for version 105600 or later for nil_ and nil otherwise).Vezzra wrote:I removed the _ from all nil_ occurrences...
After the above addition, yes.Shall I commit these changes?)
If I remember, I'll post some patches that go part way to turning on zipped xml serialization. This should add dependencies to zlib (if not already present due to using libpng), and presumably iostreams with zlib built in.The zlib stuff also seems to work...
Also, it is expected that the SDL/SDK branch has broken parsing for ship parts still, so don't be surprised if that (and possibly also buidlings?) aren't parsed properly...
Re: Should SDL be used as the GUI instead of Ogre?
Done.Geoff the Medio wrote:That will break on 1.56 or later, so it should be put into a boost version #if check for version 105600 or later for nil_ and nil otherwise).Vezzra wrote:I removed the _ from all nil_ occurrences...
Done. I also committed the fix for UI/ShaderProgram.cpp mentioned above.After the above addition, yes.Shall I commit these changes?)
There is still this fix to a build error on OSX that needs to be committed:
Not a final solution, but unless a more complete fix is provided I'd like to commit that as is so at least building on OSX works without having to apply this fix locally. Is that ok?Vezzra wrote:Same here, although I solved them by replacingMitten.O wrote:There were some issues with glew and opengl definitions.withCode: Select all
#include <GL/glew.h>
on line 35 in GG/Base.h. That probably can be done better, but I wanted to get the thing working first. I guess we want to patch something together that works for all supported platforms...Code: Select all
#ifdef __MACOSX__ #include <SDL2/SDL_opengl.h> #include <OpenGL/glu.h> #else #include <GL/glew.h> #endif
Yep, ship parts and buildings are broken.Also, it is expected that the SDL/SDK branch has broken parsing for ship parts still, so don't be surprised if that (and possibly also buidlings?) aren't parsed properly...
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Should SDL be used as the GUI instead of Ogre?
This issue probably isn't new to the recent changes, as OpenGL has been in use prior to this. What does trunk do for equivalent includes?Vezzra wrote:Code: Select all
#include <GL/glew.h>
Re: Should SDL be used as the GUI instead of Ogre?
I'm reading r7713 and am wondering if moving all those ifdeffery in a centralized header (fo_boost_compat.h ?) wouldn't be cleaner ?
All the patches I'll provide for freeorion will be released under the GPL v2 or later license.
Let's unleash the dyson forest powa!
Let's unleash the dyson forest powa!