Building libopenmpt in Xcode (for iOS)

[florist]

I've been experimenting a bit with premake5 xcode project generation, and I got the openmpt-trunk to build in xcode with the changes attached in the message (premake_xcode_patch.txt)

The patch contains the following changes:
1) some header search paths adjusted: ogg headers are included with angle bracket style which requires them to be in the system header search path on xcode (mpt-libopenmpt.lua, ext-vorbis.lua, ext-ogg.lua)
2) explicitly turned on build flag -std=c++14 to tell xcode to gracefully cope with some recent changes in openmpt C++ code (mpt-libopenmpt.lua)
3) filtered out the visual studio specific warning elimination flags wd4101, /wd4244, /wd4267 when action is xcode4 (ext-vorbis.lua)

After applying the patch, you can run premake to generate the xcode workspace / project files

Code: [Select]

premake5 ---file=build/premake/premake.lua --group=libopenmpt --os=macosx xcode4
Then you can open libopenmpt.xcodeproj in xcode. The xcode module in premake seems to be a bit dated, and xcode will suggest some updates to be done to the file once you open the project. I have not delved further into the premake xcode module sources yet, it might be rather lightweight changes to make the output match more recent xcode and also to support iOS in addition to macosx in the code generation.

If you're building for macOS (osx), you're good to go. I'm building libopenmpt for iOS, so a couple of changes in the build settings are needed (premake does not support ios as platform atm) :

• Set Base SDK to "Latest iOS"
• Set Architectures to "Standard architectures"

Now I can get i386 binary by building for iPhone5 simulator, x86_64 binary by building for iPhone5s or later and arm binaries by building for iOS device (or archiving in xcode terms). The xcode project generated by premake is set up for desktop, so some terminal magic is needed to get a fat .a file if you like to work with a single static lib. In short, I ran the builds, collected the resulting architecture specific binaries, and used lipo tool to create a universal binary.

It will require some additional time & effort to end up with something that could be used to produce automated releasable packaging without any manual steps, but if you're on macOS/iOS the above guideline will get you going.

I hope we can get the lua file modifications in trunk provided that they won't break existing builds/tests.

[manx]

Thanks for the effort.
I'm looking into it right now.

[manx]

A few first comments (I'll probably have more):

1) some header search paths adjusted: ogg headers are included with angle bracket style which requires them to be in the system header search path on xcode (mpt-libopenmpt.lua, ext-vorbis.lua, ext-ogg.lua)

I think this sysincludedirs is a somewhat newer feature of premake5.
Semantically, I think it makes sense to use it for the bundled external liibraries, even with MSVC. However, it does generate different MSVC project files, thus I have to verify the semantics first.

2) explicitly turned on build flag -std=c++14 to tell xcode to gracefully cope with some recent changes in openmpt C++ code (mpt-libopenmpt.lua)

It might make sense to do that for every project right below the language "C" or language "C++"  lines.
Can you please double-check that -std=c++14 is actually required instead of just -std=c++11? libopenmpt should compile in c++11 mode as that is what the autotools package uses on every platform. If it does not work on Apple, I'll happily fix the problems.
Also, this needs to be guarded with

Code: [Select]

filter { "not action:vs*" } ... filter {}.

3) filtered out the visual studio specific warning elimination flags wd4101, /wd4244, /wd4267 when action is xcode4 (ext-vorbis.lua)

Always reset the filter as it continues to apply to following options otherwise:

Code: [Select]

  filter { "action:vs*" }
    buildoptions { "/wd4101", "/wd4244", "/wd4267" }
  filter {}


Code: [Select]

-  prebuildcommands { "..\\..\\build\\svn_version\\update_svn_version_vs_premake.cmd $(IntDir)" }
+  filter { "not action:xcode4" }
+    prebuildcommands { "..\\..\\build\\svn_version\\update_svn_version_vs_premake.cmd $(IntDir)" }


Same here:

filter { "action:vs*" }
 prebuildcommands { "..\\..\\build\\svn_version\\update_svn_version_vs_premake.cmd $(IntDir)" }
filter {}

After applying the patch, you can run premake to generate the xcode workspace / project files

Code: [Select]

premake5 ---file=build/premake/premake.lua --group=libopenmpt --os=macosx xcode4

Do the various build configurations (Debug,Release,DebugShared,ReleaseShared,...) that we use for MSVC actually make sense in the xcode context? (I do not own any Apple device, thus I cannot judge that myself)

I hope we can get the lua file modifications in trunk provided that they won't break existing builds/tests.

I hope so too ;-).
Even though I commented on about every aspect here, I do not think there is anything fundamentally wrong with getting OSX support the way you did it; it's all just details.

[manx]

3) filtered out the visual studio specific warning elimination flags wd4101, /wd4244, /wd4267 when action is xcode4 (ext-vorbis.lua)

Always reset the filter as it continues to apply to following options otherwise:

Code: [Select]

  filter { "action:vs*" }
    buildoptions { "/wd4101", "/wd4244", "/wd4267" }
  filter {}


I did just that in r6852.

[manx]

2) explicitly turned on build flag -std=c++14 to tell xcode to gracefully cope with some recent changes in openmpt C++ code (mpt-libopenmpt.lua)

It might make sense to do that for every project right below the language "C" or language "C++"  lines.
Can you please double-check that -std=c++14 is actually required instead of just -std=c++11? libopenmpt should compile in c++11 mode as that is what the autotools package uses on every platform. If it does not work on Apple, I'll happily fix the problems.
Also, this needs to be guarded with

Code: [Select]

filter { "not action:vs*" } ... filter {}.

I set -std=c++11 globally in r6853 (in build/premake/premake-defaults.lua).

[florist]

You do stuff faster than I can reply c++11 seems to do the trick, you don't need c++14 in Xcode either. If you can put up a revision with the sysincludedirs changes mentioned, I can try if everything is working on Xcode then.

Regarding the configurations - debug + release would be enough for macOS/iOS builds I believe.

[Saga Musix]

Regarding the sysincludedirs option, I wonder if it wouldn't make more sense to require Homebrew for libvorbis and the like on OSX, in which case our own include path shouldn't be used.

[manx]

Regarding the sysincludedirs option, I wonder if it wouldn't make more sense to require Homebrew for libvorbis and the like on OSX, in which case our own include path shouldn't be used.

I think both variants might be useful for Apple developers. Homebrew (or whatever other packaging system comes next) if you are targeting unix-like environments like Homebrew itself, and bundled libraries if you are targeting App Store stuff (for both MacOS and iOS).
But again, I dont do Apple development ...

[florist]

I think both variants might be useful for Apple developers. Homebrew (or whatever other packaging system comes next) if you are targeting unix-like environments like Homebrew itself, and bundled libraries if you are targeting App Store stuff (for both MacOS and iOS).

I have very limited experience on desktop mac os app development, but at least for iPhone/iPad it is precisely so - Homebrew is not an option there.

[manx]

r6859 now uses sysincludedirs where appropriate.