oF 64 bit, c++11 support (only merge once os x apothecary build binaries are in master)

[tgfrerer]

I guess an image says it better than 1.000 words =):

This sets up the OS X openFrameworksLib project files and the openFrameworks project template so that you can select via drop-down whether you want to compile your openFrameworks app as 64 bit c++11, or, legacy 32 bit cpp98. Addresses #2016, #1864

---

Use

1. Use the project generator to create or update an openFrameworks project.
2. Open your project. You'll see this in the XCode top bar:
   
3. Select the build target (in my case emptyExample Debug) to either compile the Debug or the Release configuration.
   
4. Then select the target architecture (32 or 64 bit).
   

You can click the architecture dropdown to switch between architectures. Don't worry about selecting the target architecture for openFrameworks itself, that one is automatically detected from your current build target.

Also, the correct stdlib is automatically used to link everything together. In 32 bit mode, you can use cpp98 like you always did. =)

But, once you switch over to 64 bit mode, you get full c++11 support:

---

How this works

In XCode, you can set per architecture build flags. These build flags make sure that the 64 bit and the 32 bit version are compiled with the correct toolchains. The Project is set to Universal (which gives you the architecture selection dropdown), but the projects themselves are set up to only build the active architecture. This gives you either a 32 bit binary or a 64 bit binary.

I put the necessary project build settings into the CoreOF.xcconfig file. This file is included in both the App project compile settings and the openFrameworksLib project compile settings.

For the app settings, it is included at Target level, meaning the settings in CoreOF.xcconfig it will take precedent over the settings selected in the project build settings panel. (If you need to, you can still override the settings using the target build settings panel).

To update "old" project files to 64 bit, using the projectGenerator with "update project" in devApps should do.

---

Pre-Requisites

This works once apothecary has been used to compile out all necessary fat libs:

./apothecary update glfw
./apothecary update FreeImage
./apothecary update cairo
./apothecary update openssl
./apothecary update poco
./apothecary update tess2
./apothecary update fmodex

---

Preview

If you don't want to compile everything, i have a branch in my repo currently that has all that applied, and the libraries compiled, so if you pull from this, you should be able to test 64 bit / 32 bit openFrameworks quickly: https://github.com/tgfrerer/openFrameworks/tree/of_64_bit_c%2B%2B11-precompiled

[pizthewiz]

Interesting, so we cannot support Mac OS X 10.6? That is perfectly fine with me as I was advocating we drop 10.6 and 10.7, see #3507 and #3543 😉

[tgfrerer]

yes, cpp11 apparently requires 10.7+

[kylemcdonald]

thanks! looking forward to merging this once the apothecary libs are built :)

[armadillu]

Thx so much for making this happen guys!

[pizthewiz]

Technically we could merge this and i386 would continue to work. I think for x86_64, we'd need to merge #3624 and sort out the GLFW fork and upstream changes #3621 and we should be good, no? 😁

[ofTheo]

I think its okay if we want to merge this now as long as it works fine and defaults to i386.
Probably easier to merge this now than risk merge conflicts as it waits for libs.

[tgfrerer]

I'd wait just for a little bit more if possible-

the PR is quite slim and since it only touches the project files shouldn't code rot that fast, but if merged, you might end up with a not-yet-functional 64 bit target (the i386 target should be fine) which might confuse folks using master as their development branch...

That said, if there's consensus to merge earlier, I can try to figure out to make sure it defaults to i386 =)

[admsyn]

Amazing, thanks for the great writeup as well @tgfrerer :)

[bilderbuchi]

I'll just ping @openframeworks/documentation so that they're aware of this write-up which could probably be easily cannibalized for a guide on this.

[tgfrerer]

Awesome! seems we are one merge (#3624) away from being os x 32/64 bit potion-complete.
Update: the core is potion complete for OS X =) !

[pizthewiz]

@tgfrerer now that the required apothecary changes have been merged into HEAD, can this be merged as well?

[tgfrerer]

@pizthewiz it will only work (for 64bit) once the apothecary compiled binaries (and the corresponding headers) are in master. In the meantime, if run apothecary on your machine and recompile all core libraries using it, you should already be able to apply this PR and run 64bit/c++11 on OS X.

I believe a recent #define change for RPI has broken the auto-merge for this PR. It's probably just manually merging that line in ofTypes.h. I'll see to update the PR tomorrow morning to keep it fresh.

[carthach]

Howya!

Great work with this and kudos on the clear instructions.

I had some issues loading fonts with missing symbols for freetype like this:-

Undefined symbols for architecture x86_64:
"_hb_ft_font_create", referenced from:
_af_face_globals_new in freetype.a(autofit.o)

However it works fine linking to my universal homebrew version of freetype. I then managed to get it working with openFrameworks' version by adding "--without-harfbuzz" to freetype.sh.

Not sure if this affects others, hope it might be of some use...

[tgfrerer]

hey @carthach, that's great to know!

As far as i could find out, the harfbuzz dependency has been added to Freetype 2.5.3 and is used to scan advanced OpenType layout features (see: freetype.org). It seems sensible to exclude it for now, as FreeType seems to work fine in most cases and provides the switch you found.

Also, Freetype are apparently exploring the possibility of merging some of harfbuzz's features into their codebase.

I guess if someone absolutely needs these advanced layout features, linking to a homebrew version of freetype like you did would make a lot of sense. I wonder, did you see any differences in text rendering between the homebrew and the apothecary version of freetype once you got the latter working?

Ping @openframeworks/typography

Do you mind sending a PR to the apothecary recipe for freetype adding the switch you found?

[carthach]

Sorry maybe I wasn't clear, the homebrew script has the no harfbuzz tag as well, that's where I got the idea for the fix.

I'll do a PR no problem.

[kylemcdonald]

is it possible for you to add commits for the precompiled binaries as well? then we should be able to merge and work with it immediately, correct?

it would be good to merge this while we're filling all out apothecary / c++11 / 64-bit. the repo will get bigger again, but it's temporary :)

[ofTheo]

@tgfrerer the OS X 64bit libs are now in master and 10.8 is set as the default target. Do you want to update your PR so we can merge it in?

[tgfrerer]

@ofTheo i've just merged it manually on my mac, and tested OSX cpp11, and cpp98, which works =)
the only merge conflict i had was in ofTypes, the ifdef for the different platforms checking for c++11 availability, which i updated manually. The coreOF conflict was just a line-ending thing.

[ofTheo]

whohoo!
thanks @tgfrerer

[armadillu]

woah is this what I think it is?

[ofTheo]

@armadillu yes. you might need to use the apps/devApps/projectGenerator to regenerate the Xcode files - but then you can build both 64bit or 32bit apps.