Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Mac - building SFML app bundle from command line  (Read 1715 times)

0 Members and 2 Guests are viewing this topic.

hiromorozumi

  • Newbie
  • *
  • Posts: 2
    • View Profile
    • Email
Mac - building SFML app bundle from command line
« on: April 01, 2017, 01:24:13 pm »
Hi,

I am trying to build an app bundle for OSX that uses the SFML 2.4.2 C-lang version. I use the following 'make' command to build my application that uses the Graphics, Windows and System SFML modules along with a few other libraries:

MACEXE = beepcomp
CPPFILES = Config.cpp MData.cpp DData.cpp Astro.cpp LFO.cpp Fall.cpp OSC.cpp NOSC.cpp DelayLine.cpp MML.cpp MPlayer.cpp Dialog.cpp Button.cpp Knob.cpp GUI.cpp main.cpp
MACINCLUDEPATHS = -I./include -I/usr/local/include
MACLIBPATHs = -L/usr/local/lib
MACLIBFLAGS = -lsndfile -lmp3lame -lportaudio -framework sfml-graphics -framework sfml-window -framework sfml-system

mac:
        clang++ -stdlib=libc++ $(CPPFILES) $(MACINCLUDEPATHS) $(MACLIBPATHS) $(MACLIBFLAGS) -o $(MACEXE)
 

Once compiled, I use an independent program called "Mac Dylib Bundler" along with my own shell script to make sure:

- All dependent .dylib files are copied in "BeepComp.app/Contents/libs" folder
- All dependent frameworks are copied in "BeepComp.app/Contents/Frameworks" folder
- Use install_name_tool to register the paths to all .dylib files
- Use install_name_tool to add "rpath" pointing to the above framework paths

When I test the produced app bundle, the bundle seems to work okay on the two Macs I have.

I examined the sample app bundle built in Xcode using the SFML App template, just to see what an ideal app bundle should look like. Running otool on the executable, these show up as dependencies for Xcode-produced executable but not on the executable I built:

- libobjc.A.dylib
- framework.Foundation
- framework.CoreFoundation

Do I need to explicitly link against these libraries when I compile my application? And if I do, do I need to include these libraries in the "(appname).app/Contents/Frameworks" folder? I am guessing that these are included in the Mac OS and that's why my bundle runs without bundling with them. But I just wanted to ask what the recommended way is as far as preparing a distributable SFML app outside Xcode. I would appreciate any advice! :)

Kind regards,
Hiro
« Last Edit: April 01, 2017, 01:38:51 pm by hiromorozumi »

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
Re: Mac - building SFML app bundle from command line
« Reply #1 on: April 02, 2017, 05:27:13 pm »
Do I need to explicitly link against these libraries when I compile my application? And if I do, do I need to include these libraries in the "(appname).app/Contents/Frameworks" folder? I am guessing that these are included in the Mac OS and that's why my bundle runs without bundling with them. But I just wanted to ask what the recommended way is as far as preparing a distributable SFML app outside Xcode. I would appreciate any advice! :)

Your guess is correct: those are system libraries that you do not need to ship with your app (it might actually cause issues if you do).

As for the linking, if I remember correctly, those are needed by the resourcePath function that we ship with the Xcode templates. If you're not using this function, try not linking against those: if it works, then you don't need them -- it's that simply.  ;)
SFML / OS X developer

hiromorozumi

  • Newbie
  • *
  • Posts: 2
    • View Profile
    • Email
Re: Mac - building SFML app bundle from command line
« Reply #2 on: April 03, 2017, 04:09:01 am »
Hi Hiura,

Thank you for your helpful answer! I did read in another post that the system libraries that come with the OS as default are better off untouched, like you suggest. I suppose that the same goes for anything that the OS installs in /usr/lib - libc++.1.dylib and libSystem.B.dylib for example. So we shouldn't ship with our own copies of these dylibs or change the paths where our SFML app executable looks for these.

 

anything