OGRE (Object-Oriented Graphics Rendering Engine) Static Port

[marin.saric@…]

This is a ground-up rework of OGRE port designed to deploy static binaries on MacOS X in a similar fashion to the Linux port. This port is not a variant of the existing Ogre port; it includes major changes to the build system and a re-work to make it function much more like its Linux counterpart.

This is currently the only version of OGRE for MacOS X that allows the user to run the tutorial code on the OGRE website and the only version of OGRE for MacOS X which runs the Sample code under a static build.

It is also by far the easiest version to install and get started in. There are many fixes to the CMakefiles and Find*.cmake macros to enable small CMakeLists.txt projects that work using a simple cmake/make invocation.

There is a README file and the tutorial code from the OGRE website has been adapted to run on MacOS X. This required including a separate Cocoa-based module, since the OGRE MacOS X port is missing the required Cocoa-driving code.

It is currently impossible to install both ogre and ogre-static, since OGRE header files and the library behavior by design changes if a static build is active.

Static binary support was introduced to OGRE relatively recently. Unlike the MacOS X version on the OGRE website and the OGRE version currently in MacPorts, ogre-static (this version) builds using only CMake, without any explicit reliance on XCode. It is designed to produce simple executables that do not depend on any libraries other than the most basic MacOS X system frameworks (this can be verified with otool -L). In a source-based distribution like MacPorts, a dynamically linked variant of Ogre offers very few advantages and many possible pitfalls once a MacPorts-based application needs to be deployed.

This OGRE port has been successfully used in a scientific application that also uses OpenCV and runs inside MATLAB that has been deployed on Linux without any code changes.

The aim of this port is to become officially supported by the OGRE project. Once it is available in MacPorts, the maintainer will contact the OGRE developer community for feedback and enhancement requests.

[marin.saric@…]

Portfile for ogre-static

[ryandesign (Ryan Carsten Schmidt)]

Replying to marin.saric@…:

It is currently impossible to install both ogre and ogre-static, since OGRE header files and the library behavior by design changes if a static build is active.

This conflict should be indicated by adding the line

conflicts ogre

to the port (and the corresponding conflicts ogre-static to the ogre port).

I don't like patching their software so much, but if you believe you can get the developers to include them in a future version, then we could add the port, to show them how it would work.

[marin.saric@…]

Definitely!

I am going to work with the OGRE team to upstream this so it's ready for Ogre 1.8 which will come out end of this year or early next year. OGRE just very recently switched to CMake (in v1.7.3), so the MacOS X side of the CMake build was still in early development. I made sure my CMakeLists.txt changes don't mess with the existing ports, including the existing MacOS SDK build.

It's a kind of a chicken and egg problem, but if I can show them, sudo port install ogre-static and everything magically works, I think it's a powerful demo.

The ultimate goal is to make code built with OIS and OGRE able to be recompiled for Linux, MacOS and Windows without any code changes, and I think it can be achieved as early as next release of OGRE. Having this in would help tremendously!

Thanks for telling me about the conflicts keyword. I was hoping something like that exists, I knew it was there for variants. I just saw it in the Portfile example in ​section 4.7.6 Renaming or replacing a port. It should probably be documented in ​section 5.1 Global Keywords..

I don't have SVN access yet... I hope to apply soon. Is it OK if you make the "conflicts" change to the Portfile(s)?

[mamoll (Mark Moll)]

As I mentioned in #30688 I would favor just one (working) ogre port, so replacing the existing ogre port with this one seems like a reasonable thing to do.

[marin.saric@…]

Perfect, thanks Mark! I think we both share some interests because I got interested in OGRE as a part of a scientific project (robotics, computer vision and machine learning)..

There's already a platform on which a static build is default (iPhone), so this wouldn't even be too strange..

Ryan, is it ok that we then rename ogre-static to ogre and just check it in as version 1.7.3 revision 3?

I am ready to actively maintain this port and upstream as fast as possible to OGRE..

[ryandesign (Ryan Carsten Schmidt)]

I'm in favor of there being a single ogre port instead of two. If Mark is ok with replacing the existing ogre port with this new one, then it's fine with me. I'll let you two work out which of you (or both) want to maintain the new port. Mark, you could commit the changes at your convenience.

[ryandesign (Ryan Carsten Schmidt)]

Replying to marin.saric@…:

There's already a platform on which a static build is default (iPhone), so this wouldn't even be too strange..

Remember however that MacPorts runs on OS X, not iOS. On OS X, dynamic libraries, not static libraries, are usually preferred. But there might be rare exceptions, and ogre might be one of them. I certainly don't want to stand in the way of improving ogre's cross-platform consistency or making it easier for developers to use, and if making it static accomplishes that, then go for it.

[mamoll (Mark Moll)]

I am a little confused why the port installs a bunch of stuff in $applications_dir that are not applications. Wouldn't ${prefix}/share/doc/OGRE be more appropriate?

[mamoll (Mark Moll)]

I committed marin.saric's Portfile and patches in r87836, but installed everything that was in ${applications_dir} in ${prefix}/share/doc.