1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
|
---
short-description: Tools to create OS X packages
...
# Creating OSX packages
Meson does not have native support for building OSX packages but it
does provide all the tools you need to create one yourself. The reason
for this is that it is a very hard task to write a system that
provides for all the different ways to do that but it is very easy to
write simple scripts for each application.
Sample code for this can be found in [the Meson manual test
suite](https://github.com/jpakkane/meson/tree/master/manual%20tests/4%20standalone%20binaries).
## Creating an app bundle
OSX app bundles are actually extremely simple. They are just a
directory of files in a certain format. All the details you need to
know are on [this
page](https://stackoverflow.com/questions/1596945/building-osx-app-bundle)
and it is highly recommended that you read it first.
Let's assume that we are creating our app bundle into
`/tmp/myapp.app`. Suppose we have one executable, so we need to
install that into `Contents/MacOS`. If we define the executable like
this:
```meson
executable('myapp', 'foo1.c', ..., install : true)
```
then we just need to initialize our build tree with this command:
```console
$ meson --prefix=/tmp/myapp.app \
--bindir=Contents/MacOS \
builddir \
<other flags you might need>
```
Now when we do `meson install` the bundle is properly staged. If you
have any resource files or data, you need to install them into
`Contents/Resources` either by custom install commands or specifying
more install paths to the Meson command.
Next we need to install an `Info.plist` file and an icon. For those we
need the following two Meson definitions.
```meson
install_data('myapp.icns', install_dir : 'Contents/Resources')
install_data('Info.plist', install_dir : 'Contents')
```
The format of `Info.plist` can be found in the link or the sample
project linked above. The simplest way to get an icon in the `icns`
format is to save your image as a tiff an then use the `tiff2icns` helper
application that comes with XCode.
Some applications assume that the working directory of the app process
is the same where the binary executable is. If this is the case for
you, then you need to create a wrapper script that looks like this:
```bash
#!/bin/bash
cd "${0%/*}"
./myapp
```
install it with this:
```meson
install_data('myapp.sh', install_dir : 'Contents/MacOS')
```
and make sure that you specify `myapp.sh` as the executable to run in
your `Info.plist`.
If you are not using any external libraries, this is all you need to
do. You now have a full app bundle in `/tmp/myapp.app` that you can
use. Most applications use third party frameworks and libraries,
though, so you need to add them to the bundle so it will work on other
peoples' machines.
As an example we are going to use the [SDL2](https://libsdl.org/)
framework. In order to bundle it in our app, we first specify an
installer script to run.
```meson
meson.add_install_script('install_script.sh')
```
The install script does two things. First it copies the whole
framework into our bundle.
```console
$ mkdir -p ${MESON_INSTALL_PREFIX}/Contents/Frameworks
$ cp -R /Library/Frameworks/SDL2.framework \
${MESON_INSTALL_PREFIX}/Contents/Frameworks
```
Then it needs to alter the library search path of our
executable(s). This tells OSX that the libraries your app needs are
inside your bundle. In the case of SDL2, the invocation goes like
this:
```console
$ install_name_tool -change @rpath/SDL2.framework/Versions/A/SDL2 \
@executable_path/../FrameWorks/SDL2.framework/Versions/A/SDL2 \
${MESON_INSTALL_PREFIX}/Contents/MacOS/myapp
```
This is the part of OSX app bundling that you must always do
manually. OSX dependencies come in many shapes and forms and
unfortunately there is no reliable automatic way to determine how each
dependency should be handled. Frameworks go to the `Frameworks`
directory while plain `.dylib` files usually go to
`Contents/Resources/lib` (but you can put them wherever you like). To
get this done you have to check what your program links against with
`otool -L /path/to/binary` and manually add the copy and fix steps to
your install script. Do not copy system libraries inside your bundle,
though.
After this you have a fully working, self-contained OSX app bundle
ready for distribution.
## Creating a .dmg installer
A .dmg installer is similarly quite simple, at its core it is
basically a fancy compressed archive. A good description can be found
on [this page](https://el-tramo.be/guides/fancy-dmg/). Please read it
and create a template image file according to its instructions.
The actual process of creating the installer is very simple: you mount
the template image, copy your app bundle in it, unmount it and convert
the image into a compressed archive. The actual commands to do this
are not particularly interesting, feel free to steal them from either
the linked page above or from the sample script in Meson's test suite.
## Putting it all together
There are many ways to put the .dmg installer together and different
people will do it in different ways. The linked sample code does it by
having two different scripts. This separates the different pieces
generating the installer into logical pieces.
`install_script.sh` only deals with embedding dependencies and fixing
the library paths.
`build_osx_installer.sh` sets up the build with the proper paths,
compiles, installs and generates the .dmg package.
The main reasoning here is that in order to build a complete OSX
installer package from source, all you need to do is to cd into the
source tree and run `./build_osx_installer.sh`. To build packages on
other platforms you would write scripts such as
`build_windows_installer.bat` and so on.
|
