Page 1 of 1

Apple Mac Xcode updates and dependencies

Posted: Mon Jun 16, 2008 12:10
by CrazyEddie
Here at the CEGUI project we now once again have access to a Mac, and as such are now able to more readily update the Xcode projects and to ensure CEGUI builds and runs on the Mac.

To this end, I am able to announce that various work has been done recently in the v0-6 branch in order to get CEGUI working on the Mac once again.

Basically, this is an update / cleanup of the previous Xcode project (the one in the Xcode2 directory, the other one is defunct). The Xcode project now includes all the major 'core' parts of CEGUI, including all the samples, which should now all build and run.

While the project was always structured to embed CEGUI related frameworks into the executable apps, these were not being used, and required that the framework be copied into /Library/Frameworks; this has now been fixed so that there is no need to have the CEGUI frameworks 'installed' the embedded version is now correctly used.

The project has been updated on a Mac running Xcode 3, but hopefully it should still work on Xcode 2.

We are now also providing a precompiled dependencies package. This contains all the dependency libraries built as frameworks. These frameworks were built in such a way that they are intended to be embedded within the CEGUI component that uses them (again to save needing to have your users or whatever from having to copy files all around the place). The end result is completely self-contained apps. In the real world, you might need to be a bit more selective about what you package inside the various frameworks (i.e. you would not normally supply all the XML parser modules nor all the ImageCodec modules).

The Mac dependencies are available here: http://downloads.sourceforge.net/crayze ... .1-mac.zip

This has all been tested and works fine on an otherwise stock installation of Leopard. The Mac we have is of the Intel variety, so while everything has been built as universal binaries, we have not tested the PowerPC parts - so feedback is welcome on the success or otherwise of owners of PPC based Macs.

CE.

Posted: Tue Jun 17, 2008 18:28
by CrazyEddie
Quick update / heads-up about a potential 'issue'.

The common usage is obviously for the embedded copies of the frameworks to go into the "Contents/Frameworks" directory in the application bundle. Now, due to the fact that I was updating the existing project files, this is not where the frameworks get put; they get put (as they always had been) in the "Contents/Resources" directory.

Obviously this situation may not be not ideal, but because the current work was put in for what will be a maintenance release (0.6.1), I decided not to change it.

The upcoming 0.7.0 release will have things done in the more standard way.

CE.

Posted: Thu Jun 26, 2008 01:05
by Auria
Hi,

thanks for the work, I was exactly trying to get it to run on mac at the moment :)

I came up with this patch that should make it buildable by the autotools as well as by XCode, what do you think?

Code: Select all

Index: cegui/include/CEGUIDynamicModule.h
===================================================================
--- cegui/include/CEGUIDynamicModule.h   (revision 1781)
+++ cegui/include/CEGUIDynamicModule.h   (working copy)
@@ -34,6 +34,13 @@
     The following is basically taken from DynLib.h, which is part of
     the Ogre project (http://www.ogre3d.org/)
 *************************************************************************/
+
+// define '__APPLE_FRAMEWORKS__' if you wish to build CEGUI
+// into frameworks (in XCode) and not using the autotools
+#if defined(__APPLE__) && !defined(__APPLE_FRAMEWORKS__)
+#define __APPLE_UNIX__ 1
+#endif
+
 #if defined(__WIN32__) || defined(_WIN32)
 #   define DYNLIB_HANDLE hInstance
 #   define DYNLIB_LOAD( a ) LoadLibrary( a )
@@ -42,21 +49,25 @@
     struct HINSTANCE__;
     typedef struct HINSTANCE__* hInstance;
 
-#elif defined(__linux__)
+#elif defined(__APPLE_FRAMEWORKS__)
+#    include <CoreFoundation/CFBundle.h>
+#    define DYNLIB_HANDLE CFBundleRef
+#    define DYNLIB_LOAD( a ) mac_loadExeBundle( a )
+#    define DYNLIB_GETSYM( a, b ) mac_getBundleSym( a, b )
+#    define DYNLIB_UNLOAD( a ) mac_unloadExeBundle( a )
+#    define DYNLIB_ERROR( ) mac_errorBundle()
+
+#elif defined(__linux__) || defined(__APPLE_UNIX__)
+#    include <dlfcn.h>
 #    define DYNLIB_HANDLE void*
 #    define DYNLIB_LOAD( a ) dlopen( a, RTLD_LAZY )
 #    define DYNLIB_GETSYM( a, b ) dlsym( a, b )
 #    define DYNLIB_UNLOAD( a ) dlclose( a )
 #    define DYNLIB_ERROR( ) dlerror( )
 
-#elif defined(__APPLE_CC__)
-#    define DYNLIB_HANDLE CFBundleRef
-#    define DYNLIB_LOAD( a ) mac_loadExeBundle( a )
-#    define DYNLIB_GETSYM( a, b ) mac_getBundleSym( a, b )
-#    define DYNLIB_UNLOAD( a ) mac_unloadExeBundle( a )
-#    define DYNLIB_ERROR( ) mac_errorBundle()
 #endif
 
+
 // Start of CEGUI namespace section
 namespace CEGUI
 {
Index: cegui/src/RendererModules/OpenGLGUIRenderer/opengltexture.cpp
===================================================================
--- cegui/src/RendererModules/OpenGLGUIRenderer/opengltexture.cpp   (revision 1781)
+++ cegui/src/RendererModules/OpenGLGUIRenderer/opengltexture.cpp   (working copy)
@@ -146,7 +146,7 @@
     size = getSizeNextPOT(size);
 
    // make sure size is within boundaries
-   int maxSize;
+   GLint maxSize;
    glGetIntegerv(GL_MAX_TEXTURE_SIZE, (GLint*)&maxSize);
    if (size > (uint)maxSize)
    {
Index: cegui/src/implementations/mac/macPlugins.cpp
===================================================================
--- cegui/src/implementations/mac/macPlugins.cpp   (revision 1781)
+++ cegui/src/implementations/mac/macPlugins.cpp   (working copy)
@@ -24,6 +24,10 @@
  *   ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  *   OTHER DEALINGS IN THE SOFTWARE.
  ***************************************************************************/
+#ifdef __APPLE_FRAMEWORKS__
+// define '__APPLE_FRAMEWORKS__' if you wish to build CEGUI
+// into frameworks (in XCode) and not using the autotools
+
 #include <CoreFoundation/CoreFoundation.h>
 #include "macPlugins.h"
 #include "CEGUILogger.h"
@@ -163,3 +167,5 @@
      }
 
 }
+
+#endif
\ No newline at end of file
Index: cegui/src/implementations/mac/macPlugins.h
===================================================================
--- cegui/src/implementations/mac/macPlugins.h   (revision 1781)
+++ cegui/src/implementations/mac/macPlugins.h   (working copy)
@@ -24,6 +24,10 @@
  *   ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  *   OTHER DEALINGS IN THE SOFTWARE.
  ***************************************************************************/
+#ifdef __APPLE_FRAMEWORKS__
+// define '__APPLE_FRAMEWORKS__' if you wish to build CEGUI
+// into frameworks (in XCode) and not using the autotools
+
 #include <CoreFoundation/CoreFoundation.h>
 
 namespace CEGUI
@@ -33,3 +37,5 @@
     bool mac_unloadExeBundle(CFBundleRef bundle);
     const char *mac_errorBundle();
 }
+
+#endif
\ No newline at end of file
Index: cegui/src/CEGUIDynamicModule.cpp
===================================================================
--- cegui/src/CEGUIDynamicModule.cpp   (revision 1781)
+++ cegui/src/CEGUIDynamicModule.cpp   (working copy)
@@ -43,7 +43,7 @@
 #endif
 
 #if defined(__APPLE_CC__)
-#   include "macPlugins.h"
+#   include "implementations/mac/macPlugins.h"
 #endif
 
 #if defined(__linux__)
@@ -68,7 +68,12 @@
     // dlopen() does not add .so to the filename, like windows does for .dll
     if (d_moduleName.substr(d_moduleName.length() - 3, 3) != ".so")
         d_moduleName += ".so";
+#elif defined(__APPLE_UNIX__)
+    // dlopen() does not add .dylib to the filename, like windows does for .dll
+    if (d_moduleName.substr(d_moduleName.length() - 6, 6) != ".dylib")
+        d_moduleName += ".dylib";
 #endif
+       
     // Optionally add a _d to the module name for the debug config on Win32
 #if (defined(__WIN32__) || defined(_WIN32))
 #   if defined (_DEBUG) && defined (CEGUI_LOAD_MODULE_APPEND_SUFFIX_FOR_DEBUG)
@@ -80,7 +85,7 @@
 
     d_handle = DYNLIB_LOAD(d_moduleName.c_str());
 
-#if defined(__linux__) || defined(__MINGW32__)
+#if defined(__linux__) || defined(__MINGW32__) || defined(__APPLE_UNIX__)
     if (!d_handle)
     {
         // see if we need to add the leading 'lib'


The major advantage of allowing compilation from terminal is that CEGUI could then enter package management tools like macports, it would also be easier to build it this way when building projects from linux (i.e. less necessary to change their build system)

Posted: Thu Jun 26, 2008 08:08
by CrazyEddie
Hi,

Thanks for the patch.

The other day I kind of looked very, very briefly at getting support for building via autotools - at the time I thought it was something not particularly worth supporting. However, your comment about easier interoperability with other packages that use a command line build, and expect their dependencies, such as CEGUI, to be available via the same system makes me think that initial judgement was a little rash :)

We just locked down the code for the 0.6.1 release (literally, last night) - so I can't add this to that release, since I do not have the time to fully test :) However, I'll test out the patch and get it in for the following release (which is likely to be 0.7.0 - but don't rule out 0.6.2 if progress is slow!).

Thanks again,

CE.

Posted: Sun Jun 29, 2008 15:25
by Auria
After this patch, the only thing left to do would be to make it use '-framework OpenGL' instead of '-lGL' (though i'm not too used to autotools so i can't find where to change that)

I'll test the XCode project too as soon as it's fixed (it was broken after the code layout change i would believe)

Posted: Sun Jun 29, 2008 17:09
by CrazyEddie
Auria wrote:After this patch, the only thing left to do would be to make it use '-framework OpenGL' instead of '-lGL' (though i'm not too used to autotools so i can't find where to change that)

Yeah, I know how to do this easily enough ;)

Auria wrote:I'll test the XCode project too as soon as it's fixed (it was broken after the code layout change i would believe)

Ah, you're on trunk? The existing Xcode project in trunk is going in the bin, and a new one is going to be created (possibly as early as next weekend) - the updates referred to in this thread were done in the v0-6 branch, mainly to start getting Mac support back on track.

CE.