SirBlack
10-07-2010 23:19:04
I've come into this as someone who has heard of MyGUI for a while, but this is the first time I've actually tried build it. Furthermore, I have virtually no knowledge about CMake. That being the case, I encountered several issues trying to build MyGUI 3.0.1 and so I have some suggestions and a couple questions.
In my case, I am using:
Windows 7
Visual Studio 2008
MyGUI 3.0.1 source download
OGRE 1.7.1 SDK and dependencies
Issue 1:
The Readme.txt says "Use CMake" and then leaves the user on their own for how to actually do that. No mention of dependencies or any other issues. No explanation of the expected results (files) of building this library. Not even a link to useful information on these subjects. Certainly, it's not too hard to track down http://www.ogre3d.org/tikiwiki/MyGUI+Compiling for this information. But I generally expect the documentation in a source download to tell me more directly how to make use of it.
Suggestion: Either put useful information in the Readme or at least put in a link to that wiki page.
Issue 2:
MYGUI_DEPENDENCIES_DIR defaults to just "Dependencies" even though CMake detects that I have OGRE present.
Suggestion: Is there a way to have CMake default it to OGRE_HOME\Dependencies when OGRE is present?
Issue 3:
If someone builds the dependencies for Debug but accidentally forgets to build them for Release, CMake will silently configure the various Release versions of MyGUI projects to use the Debug versions of OIS and FreeType.
Suggestion: Is there some way to have CMake complain about that scenario?
Issue 4:
Despite the wiki's claim that the only dependency is FreeType, the OGRE-related parts will require Boost. Furthermore, most of those require the Boost thread library to be built. The biggest problem in this is that because CMake doesn't seem to be aware of this dependency, there is no current way to for it to put the proper include and library paths in the generated project files. And if I don't want to add Boost stuff to the global directory settings in Visual Studio, then altering 16 projects in MyGUI to have the necessary paths is quite tedious.
Suggestion: Document the dependency on Boost. Also provide a way in CMake to auto-detect and/or specify the necessary Boost paths.
Issue 5:
In my setup, I found those various MyGUI projects wanting to link against the thread lib from Boost 1.43, which happens to be what I have on my system. This is without me giving any indication of while Boost version to build against. (In fact, I have no idea how the MyGUI projects are deciding they need that specific version of the lib.) However, the OGRE SDK was evidently built against Boost 1.42. Is having components built against those two different versions of Boost going to present any problems? Is it OK or do I need to track down where MyGUI is getting this specific dependency from and change it? Or do I need to work against a locally compiled version of OGRE instead of the pre-built SDK?
Suggestion: Clarify this Boost version issue.
Issue 6:
After finally getting everything built, the wiki at least mentions where to find the include and lib folders. However there is no mention of the tools or demo programs. Ok, I found them in the bin folder. Of course, I can't just run them from there because the necessary OGRE dlls are not present. Is that the final destination for those executables or were they supposed to end up somewhere else as well? Was any part of the build process supposed to copy in the necessary OGRE dlls? Or is it intended for the user to manually sort this out? I don't mind copying some executables or dlls around. But without having any documentation on what to expect, I don't know whether it's supposed to be this way or whether a post-build process failed. And it would certainly be nice if there was a post-build step that could perform the necessary copying.
Suggestion: Document the expected results of a proper build of the tool and demo projects.
Suggestion: If possible, provide a post-build step so that the executables are runnable.
Issue 7:
While trying to discover if there is supposed to be a build process that puts all the executables somewhere usable, I noticed the INSTALL project. I tried building it, but all that seemed to happen was it copied various MyGUI files to folders under "sdk". Is there an actual purpose for this? I would have guessed that INSTALL might actually install the executables and such to a runnable location. Otherwise, it seems to have no significant use since I can already get to those various files in their non-sdk locations.
Suggestion: Document what INSTALL is for. If it currently has no purpose (at least on my configuration) then at least document that.
Please don't take this as just complaining. I know I can help add more information to the wiki. But as it stands, I feel like I could contribute only a trivial amount of information (or else just work-arounds for issues that ought to be solved in better ways).
In my case, I am using:
Windows 7
Visual Studio 2008
MyGUI 3.0.1 source download
OGRE 1.7.1 SDK and dependencies
Issue 1:
The Readme.txt says "Use CMake" and then leaves the user on their own for how to actually do that. No mention of dependencies or any other issues. No explanation of the expected results (files) of building this library. Not even a link to useful information on these subjects. Certainly, it's not too hard to track down http://www.ogre3d.org/tikiwiki/MyGUI+Compiling for this information. But I generally expect the documentation in a source download to tell me more directly how to make use of it.
Suggestion: Either put useful information in the Readme or at least put in a link to that wiki page.
Issue 2:
MYGUI_DEPENDENCIES_DIR defaults to just "Dependencies" even though CMake detects that I have OGRE present.
Suggestion: Is there a way to have CMake default it to OGRE_HOME\Dependencies when OGRE is present?
Issue 3:
If someone builds the dependencies for Debug but accidentally forgets to build them for Release, CMake will silently configure the various Release versions of MyGUI projects to use the Debug versions of OIS and FreeType.
Suggestion: Is there some way to have CMake complain about that scenario?
Issue 4:
Despite the wiki's claim that the only dependency is FreeType, the OGRE-related parts will require Boost. Furthermore, most of those require the Boost thread library to be built. The biggest problem in this is that because CMake doesn't seem to be aware of this dependency, there is no current way to for it to put the proper include and library paths in the generated project files. And if I don't want to add Boost stuff to the global directory settings in Visual Studio, then altering 16 projects in MyGUI to have the necessary paths is quite tedious.
Suggestion: Document the dependency on Boost. Also provide a way in CMake to auto-detect and/or specify the necessary Boost paths.
Issue 5:
In my setup, I found those various MyGUI projects wanting to link against the thread lib from Boost 1.43, which happens to be what I have on my system. This is without me giving any indication of while Boost version to build against. (In fact, I have no idea how the MyGUI projects are deciding they need that specific version of the lib.) However, the OGRE SDK was evidently built against Boost 1.42. Is having components built against those two different versions of Boost going to present any problems? Is it OK or do I need to track down where MyGUI is getting this specific dependency from and change it? Or do I need to work against a locally compiled version of OGRE instead of the pre-built SDK?
Suggestion: Clarify this Boost version issue.
Issue 6:
After finally getting everything built, the wiki at least mentions where to find the include and lib folders. However there is no mention of the tools or demo programs. Ok, I found them in the bin folder. Of course, I can't just run them from there because the necessary OGRE dlls are not present. Is that the final destination for those executables or were they supposed to end up somewhere else as well? Was any part of the build process supposed to copy in the necessary OGRE dlls? Or is it intended for the user to manually sort this out? I don't mind copying some executables or dlls around. But without having any documentation on what to expect, I don't know whether it's supposed to be this way or whether a post-build process failed. And it would certainly be nice if there was a post-build step that could perform the necessary copying.
Suggestion: Document the expected results of a proper build of the tool and demo projects.
Suggestion: If possible, provide a post-build step so that the executables are runnable.
Issue 7:
While trying to discover if there is supposed to be a build process that puts all the executables somewhere usable, I noticed the INSTALL project. I tried building it, but all that seemed to happen was it copied various MyGUI files to folders under "sdk". Is there an actual purpose for this? I would have guessed that INSTALL might actually install the executables and such to a runnable location. Otherwise, it seems to have no significant use since I can already get to those various files in their non-sdk locations.
Suggestion: Document what INSTALL is for. If it currently has no purpose (at least on my configuration) then at least document that.
Please don't take this as just complaining. I know I can help add more information to the wiki. But as it stands, I feel like I could contribute only a trivial amount of information (or else just work-arounds for issues that ought to be solved in better ways).