6

I'm working on a multi-platform project that is composed of a service/daemon which runs on Windows, Linux, and Mac OSX.

The code I have is portable, and the application runs fine (from the command line) on all the systems. As this application is designed to run in the background, I made it a Windows service on Windows and a Linux daemon (with the appropriate scripts in init.d) for Linux.

Now my problem is Mac OSX: I have little experience with this operating system, and I am having hard times figuring out the best practices for it regarding my situation:

I'd like to have an installer for my project (I believe a .dmg file, that would likely install an .app; please correct me if there is a better alternative).

Here some information about this project of mine:

  • It is build entirely in C++ (it uses boost, curl, iconv)
  • The current build system is not XCode (however If there is a way of keeping my current code layout while integrating and building everything into XCode, I don't mind. I've done something similar for Windows anyway).
  • There is no graphical user interface
  • The daemon should start on startup automatically (or even better: make that a user's choice).
  • The daemon requires root access during its execution.

That's probably a lot of context to consider for a single question, so I will try to make it easier to read:

How would you package/create an installer for a pure-C++ daemon on Mac OSX ?

Charles
  • 50,943
  • 13
  • 104
  • 142
ereOn
  • 53,676
  • 39
  • 161
  • 238
  • If you can read french, [here](http://vincent.bernat.im/fr/blog/2013-autoconf-osx-installeur.html) is a very nice blog article that answers all my questions perfectly. – ereOn Nov 09 '13 at 15:47
  • Article also available in EN - https://vincent.bernat.ch/en/blog/2013-autoconf-osx-packaging – Murukan Oct 13 '21 at 18:55

3 Answers3

4

Since this doesn't have a UI, I wouldn't package it as a .app -- that's the preferred format for double-clickable GUI apps, not for daemons. If it's just a single binary (no support files except maybe things like config files, etc), I'd follow unix conventions and put the binary someplace like /usr/local/libexec (or wherever you put it on Linux). Note that /usr/local doesn't exist by default on OS X, so your installer will need to create it if it doesn't exist.

For getting it to execute: I'll agree with James Bedford's suggestion of using launchd. The launchd .plist file should be installed in /Library/LaunchDaemons (LaunchDaemons run as root at startup, while LaunchAgents run as normal users when that user logs in). Make sure the daemon does not drop itself into the background -- launchd keeps watch over the programs it launches, and if they background themselves it thinks they've crashed, and generally tries to relaunch them, which doesn't work very well. You can adjust the settings to work with background programs, but it's best to have it run in the foreground.

For packaging: Here, I agree with mah -- use an installer package. I actually still like the old GUI PackageMaker tool (deprecated, but it still works), but the new CLI tools are probably better to learn at this point. If you follow my recommendation about /usr/local/libexec, your package should actually contain the "local" directory (with libexec subdir and your binary in that), and install that into /usr -- if /usr/local already exists, it'll just merge with what's already there, but if not it'll create the entire thing. On the other hand, /Library/LaunchDaemons is guaranteed to exist, so your package only needs to contain the actual .plist file to put in it.

Gordon Davisson
  • 118,432
  • 16
  • 123
  • 151
  • Thank you very much @Gordon. When you talk about "the new CLI tools", are you referring to `pkgbuild` ? Also, are there any guidelines on how to embed the depended-on libraries ? (Like boost, and curl, which I basically took from homebrew. Should I compile those myself instead ?) – ereOn Nov 08 '13 at 18:46
  • 1
    Yes on `pkgbuild`. As for embedding libraries, my first thought would be to link them statically so they're just embedded in the executable and it isn't an issue. If they need to be dynamically linked, I'm not sure of the best way to bundle them. You will need to compile them and distribute them with the executable, since OS X doesn't include a compiler (unless you install one). I'd be tempted to create a subdir under /usr/local/libexec and put all the pieces there, but that's not terribly clean or standard. – Gordon Davisson Nov 09 '13 at 04:10
  • Apple's docs also recommend installing the daemon executable to `/usr/local/libexec`: https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html#//apple_ref/doc/uid/10000172i-SW7-104142-BCICCCFI – freshtop Mar 18 '16 at 16:41
3

Packaging as a .app makes some sense if what you're distributing is more than just a command line (for example, if it has resources such as static configuration data, images, frameworks/dylibs) that need to come along with it).

Regardless of what exactly is getting distributed, you can create an installer using tools that you already have -- pkgbuild and productbuild, both in /usr/bin. Making OS X Installer Packages like a Pro - Xcode Developer ID ready pkg can get you started using these tools.

Community
  • 1
  • 1
mah
  • 39,056
  • 9
  • 76
  • 93
2

Have you checked out the Daemons and Services Programming Guide provided by Apple? I think that would be very helpful as an introduction to the platform and should point you in the right direction (if not show you how to do exactly what you want).

You should also check out launchd (which is discussed in that programming guide). launchd is the official deamon launcher/manager for OSX, and is heavily integrated with the operating system. It should be easy enough to wrap your existing cross-platform deamon into a launched deamon, and you can integrate with OS X so that the deamon will start up automatically.

James Bedford
  • 28,702
  • 8
  • 57
  • 64
  • Thanks for this. It does help indeed ! (And +1 for that) Do you have any information about the packaging part of the question ? Should I make it an .app ? If so, how ? – ereOn Nov 08 '13 at 14:57