Deploying Your Application: what changed

Revision 1 to 2. Removed lines have a minus sign; added lines have a plus sign.

Old	New		Line
1	1		You've created your application in Lazarus, tested within the IDE. Now it's time to deploy it to test it on a specific platform.
2	2
3	3		## Windows Deployment
4	4
5	5		### InnoSetup
6	6
7	7		[[Inno Setup]] [1](http://www.jrsoftware.org/) is a free installer for Windows programs. It may be used completely free of charge, even when deploying commercial applications, full Delphi source code is available. See [[Inno Setup]] for more details and links to the Lazarus installer that is written using Inno.
8	8
9	9		Features:
10	10
11	11		- Inno supports all versions of Windows in use today -- Windows 95, 98, ME, NT4, 2000, 2003, XP, Vista, 7, 8. The latest version that can create installers for Windows versions before Windows 2000 is version 5.4. See [2](http://www.jrsoftware.org/files/is5-whatsnew.htm)
12	12		- It can compare file version info, replace in-use files, use shared file counting.
13	13		- It can register DLL/OCXs and type libraries
14	14		- It can install fonts.
15	15		- It can create shortcuts anywhere, including in the Start Menu and on the desktop.
16	16		- It can create registry and .INI entries
17	17		- It has integrated Pascal scripting engine that allows e.g. manipulation of COM/ActiveX objects (e.g. MS Word), setting firewall rules etc.
18	18		- It supports multilingual installs
19	19		- It supports passworded and encrypted installs
20	20		- It supports silent install and uninstall.
21	21
22	22		While it is free for use, Inno Setup is copyrighted software, not public domain software. There are some restrictions on distribution and use; see the <http://www.jrsoftware.org/files/is/license.txt> file for details.
23	23
24	24		Inno Setup is used to create the Lazarus installer for Windows.
25	25
26	26		### HJ-Install
27	27
28	28		HJ-Install is a freeware installer for Windows 95, 98, ME, NT 4.0, 2000 and XP. It is created with Internet distributed, CD-Rom, single-floppy and multi-floppy installations in mind, but it can also be used in network situations and as a stand-alone scripting engine. The installer is small and adds only 138 Kb. It doesn't support changing the registry and ini files, and un-install. See <http://www.freebyte.com/hjinstall/>
29	29
30	30		### LizaJet Installer
31	31
32	32		LizaJet Installer is a commercial installer, but a free edition is available. Uses Object Pascal for scripting. See <http://www.lizajet.com>
33	33
34	34		### NSIS (Nullsoft Scriptable Install System)
35	35
36	36		A professional open source system to create Windows installers. A full-featured NSIS installer has an overhead of only 34 KB. See <http://nsis.sourceforge.net/Main_Page> and <http://hmne.sourceforge.net/>
37	37
38	38		### Windows Installer XML (WiX) toolset
39	39
40	40		A toolset that builds Windows installation packages from XML source code. The toolset supports a command line environment that developers may integrate into their build processes to build MSI and MSM setup packages. See <http://wix.sourceforge.net/>
41	41
42	42		### Code signing
43	43
44	44		For details of code signing Windows executables to avoid your end users receiving warnings that the publisher of the software is "unknown" when attempting to run your executable, see [[Code Signing for Windows]].
45	45
46	46		## Linux Deployment
47	47
48	48		### Creating a RPM Package on Linux
49	49
50	50		On Linux, the best way to deploy applications is by using the native package system. Of the many package systems available, RPM (RedHat Package Manager) is the most commonly utilized format, and is defined as the standard one in the Linux Standard Base.
51	51
52	52		To create a RPM file, you need to create a spec text file with the information necessary to build the software, and also an environment to build that spec. The best editor to create RPM packages is Emacs, because it recognizes the spec extension, highlights the text appropriately and even has a menu option to build rpm packages.
53	53
54	54		To build the rpm file use either the emacs menu or this command line (man rpmbuild for more information):
55	55
56	56		`rpmbuild -ba --clean $HOME/RPM/SPECS/myprogram.spec`
57	57
58	58		#### Setting up your build environment
59	59
60	60		RPM Packages are installed as root to the base system (/ directory), but an accident as root can destroy your machine. To avoid this, packages can be build as a normal user. The build process includes a real install, to make sure the package works, but this install is made to a fake root directory represented by the \$RPM_BUILD_ROOT variable.
61	61
62	62		First, go to your home directory (or another directory inside it) and create the following directory structure:
63	63
64	64		- RPM
65	65		- RPM/BUILD - This directory is utilized by RPM to build the package.
66	66		- RPM/RPMS - Here you can find binary RPMs after you build them.
67	67		- RPM/SOURCES - Place your compressed tar files and patches here.
68	68		- RPM/SPECS - Place all your spec files here.
69	69		- RPM/SRPMS - Here you can find source RPMs after you build them.
70	70
71	71		Next you will need to create a configuration file to tell rpm builder software where he can find your build directories. Go to your home directory and create a file named .rpmmacros and place the text below on it. Make sure to change the directories to the correct ones on your system.
72	72
73	73		%_topdir /home/felipe/RPM/
74	74		%_tmppath /home/felipe/tmp
75	75
76	76		%_signature gpg
77	77		%_gpg_name Mandrakelinux
78	78		%_gpg_path ~/.gnupg
79	79
80	80		#### Creating a binary only package
81	81
82	82		The easiest way to create a RPM package is to make it install already compiled software. There are some reason why we might want to avoid compiling the software in the spec file:
83	83
84	84		- It requires creating a Makefile and makefiles are complex
85	85
86	86		- Some packages don't have any binary software in them, so they don't need to be built.
87	87
88	88		Each RPM Package contains a single compressed tar archive. Place the archive under the RPM/SOURCES directory. Zip, gz and bz2 compressions should work ok. The file can either contain the full source of the project if you with to create a source and a binary package or a directory with the files already in place, like if they were installed in the user machine, if you with to create a binary only package.
89	89
90	90		To build a binary package open a spec file with Emacs text editor. On Emacs open the menu "RPM spec" --\> "RPM Build" --\> "Build Binary Package". This will create a .rpm file under the directory RPM/RPMS
91	91
92	92		Below is a spec file that doesn't build the software. In this case the software is a Braille Course composed of html and Macromedia Flash files. Flash files cannot be build on Linux, so it's not possible to create a source package in this case.
93	93
94	94		%define name braillevirtual
95	95		%define version 1.0
96	96		%define release mdk
97	97		%define dir braillevirtual
98	98		%define root /home/felipe/tmp/ROOT/
99	99
100	100		Summary: Curso On-Line de Braille
101	101		Name: %{name}
102	102		Version: %{version}
103	103		Release: %{release}
104	104		Vendor: Laboratório de Brinquedos da Faculdade de Educação da USP
105	105		URL: www.braillevirtual.fe.usp.br
106	106		License: Distribuível livremente
107	107		Group: Books/Other
108	108		Packager: Felipe Monteiro de Carvalho
109	109		Source0: home/felipe/Programacao/SOURCES/braillevirtual.tar.bz2
110	110		BuildRoot: %{root}
111	111
112	112		%description
113	113		O Braille Virtual é um curso on-line público e gratuito destinado à difusão e ensino do sistema Braille de leitura e escrita para cegos a pessoas que vêem. É orientado especialmente a pais, crianças, professores e funcionários de escolas inclusivas e pretende facilitar a comunicação entre estas pessoas e as pessoas com cegueira.
114	114
115	115		%prep
116	116		cd $RPM_SOURCE_DIR
117	117		cp braillevirtual.tar.bz2 $RPM_BUILD_DIR
118	118		cd $RPM_BUILD_DIR
119	119		rm -rf %{dir}
120	120		rm -f braillevirtual.tar
121	121		bunzip2 -d braillevirtual.tar.bz2
122	122		tar -xvf braillevirtual.tar
123	123
124	124		%install
125	125		mkdir -p $RPM_BUILD_ROOT/usr/share/
126	126		rm -rf $RPM_BUILD_ROOT/usr/share/%{dir}
127	127		cp -r $RPM_BUILD_DIR/%{dir} $RPM_BUILD_ROOT/usr/share/
128	128
129	129		%clean
130	130		rm -rf $RPM_BUILD_DIR/.
131	131
132	132		%files
133	133		/usr/share/%{dir}/
134	134
135	135		%changelog
136	136
137	137		* Mon Oct 24 2005 1.0-mdk.noarch.rpm
138	138
139	139		- Nova atualização do pacote de instalação. Inclusão dos exercícios avançados.
140	140
141	141		* Wed May 12 2005 1.0-mdk.noarch.rpm
142	142
143	143		- Atualizei o pacote para refletir as mudanças no site. Várias pequenas mudanças.
144	144
145	145		* Sun May 05 2005 1.0-1mdk.i586.rpm
146	146
147	147		- O pacote de instalação do braille Virtual para linux é criado.
148	148
149	149		##### Tip:
150	150
151	151		The following packages are required for an very basic GUI Application in GTK+ (binary only):
152	152
153	153		` libc6 libx11-6 libgdk-pixbuf2.0-0 libgtk2.0-0 libglib2.0-0`\
154	154		` libpango-1.0-0 libcairo2 libatk1.0-0 libxcb1 libglib2.0-0`\
155	155		` libpangocairo-1.0-0 libxfixes3 libpangoft2-1.0-0 libfontconfig1 libxrender1`\
156	156		` libxinerama1 libxi6 libxrandr2 libxcursor1 libxcomposite1`\
157	157		` libxdamage1 libxext6 libffi6 libpcre3 libthai0`\
158	158		` libpixman-1-0 libfreetype6 libpng12-0 libxcb-shm0 libxcb-render0`\
159	159		` zlib1g libxau6 libxdmcp6 libselinux1 libharfbuzz0b`\
160	160		` libexpat1 libdatrie1 libgraphite2-3`
161	161
162	162		You can get a list of used libraries with: `ldd [executable of your project]`.
163	163
164	164		And find the packages in which it belongs:
165	165
166	166		RPM based: `rpm -qf <lib name>`
167	167
168	168		DEB based: `dpkg -S <lib name>`
169	169
170	170		Where \<lib name\> is the name of library, before =\> or ")" in list
171	171
172	172		Example: `rpm -qf libgtk-x11-2.0.so.0`
173	173
174	174		A script (DEB based) using pipes, in order to join all these commands in a single command line, could be (replace 'amd64' by 'i386' if you install 32 bits packages):
175	175
176	176		` $ ldd yourAppli \| awk '/=>/{print $(NF-1)}' \| while read n; do dpkg -S $n; done \| awk '{print $1}' \| sed 's/:amd64://' \| sort \| uniq \| while read n; do echo "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --> Usefullness of the package named $n:"; apt-cache search ^$n; echo "...which installs the following libraries on the system:"; dpkg -L $n \|grep .so; echo "...and which depends itself on the following packages on the system:"; apt show $n \| grep Depends; done;`
177	177
178	178		#### Creating a source and binary package
179	179
180	180		Linux distributions only accept RPM packages that can build the software. This will probably require creating build scripts and/or a Makefile. For more information see the section Creating a Makefile for your Lazarus software.
181	181
182	182		You need to use the %build section to compile the software. Below is an example of a spec file capable of building the software. Be very careful when studying this as every little detail is important and follows a precise pattern.
183	183
184	184		```text
185	185		Name: magnifier
186	186		Version: 3.2.1
187	187		Release: 1
188	188		Summary: Virtual Magnifying Glass
189	189		Group: Accessibility
190	190		License: GPL Version 2
191	191		URL: http://magnifier.sourceforge.net
192	192		Source0: http://internap.dl.sourceforge.net/sourceforge/magnifier/magnifier-3.2.1.zip
193	193		BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
194	194		BuildRequires: fpc >= 2.0.2, lazarus >= 0.9.12
195	195		Requires: ImageMagick
196	196
197	197		%description
198	198		Virtual Magnifying Glass is a free, open source, multiplatform, screen magnification tool. It is simple, customizable, and easy-to-use.
199	199
200	200		%prep
201	201		%setup -q magnifier
202	202		%build
203	203		make TARGET=%{_target_cpu}
204	204
205	205		%install
206	206		./install.sh DESTDIR=$RPM_BUILD_ROOT
207	207
208	208		%clean
209	209		rm -rf $RPM_BUILD_ROOT/
210	210
211	211		%files
212	212		%defattr(-,root,root,-)
213	213		/usr/share/magnifier/
214	214		/usr/bin/magnifier
215	215
216	216		%changelog
217	217		* Wed Feb 15 2006 Felipe Monteiro de Carvalho <felipemonteiro.carvalho at gmail.com> - 3.2-mdk.i386.rpm
218	218		- The Linux RPM package is created.
219	219		```
220	220
221	221		### Creating a Debian Package on Linux
222	222
223	223		Debian packages are similar to installers. They can be downloaded by users from a website or ftp. You can craft them manually from the binary file by using their [[Debian package structure\|specific structure]] and a .deb extension. However, they will not be automatically included in Debian distributions.
224	224
225	225		If you want to make a package available into Debian distributions, you need to provide a [[Debian upstream\|source upstream]] that can generate the Debian package as well as other files like the .orig.tar.gz and .dsc file. Those will be necessary for anybody to build your package for their target platform.
226	226
227	227		There is an IDE plugin here: <https://github.com/prof7bit/LazPackager>
228	228
229	229		### Creating a Pacman (Arch) Package
230	230
231	231		Please see <https://wiki.freepascal.org/pacman>
232	232
233	233		### Automating the creation of RPM and DEB packages
234	234
235	235		To simplify the work of creating RPM and DEB packages one can create a script which generates them, just like is done here:
236	236
237	237		<http://sourceforge.net/p/magnifier/code/HEAD/tree/trunk/build/build_package.sh>
238	238
239	239		### Snap
240	240
241	241		See [[Create snap package]].
242	242
243	243		### Flatpak
244	244
245	245		See [[Flatpak]].
246	246
247	247		### GUInseng
248	248
249	249		[GUInseng](http://www.guinseng.de/) is a a GTK+ based installer for Linux released under GPL.
250	250
251	251		### The Zero Install system
252	252
253	253		[The Zero Install system](http://0install.net/) is a Python based install system that aims to provide a better way of installing software than traditional systems (tarballs, apt-get, bundles, setup.exe, etc).
254	254
255	255		### Simple deployment of Lazarus application directly to Desktop Environment (e.g., KDE Plasma 5/Manjaro)
256	256
257	257		One of the first things anyone coming from Delphi/Windows environment wants to know is how to QUICKLY deploy a newly-created Linux GUI program outside of the IDE, without spending a lot of time having to first study various package management systems. Unlike Windows, Linux is a disparate collection of Distributions ("Distros" - e.g., Debian, Arch, Ubuntu, etc.) and Desktop Environments ("DE" - e.g., KDE, Gnome, XFCE, Mate, etc.) Deployment entails some knowledge of one's Disto and DE, however the learning curve and effort is a tiny fraction of the effort required to set up and use an installation package system (e.g., DEB or RPM installation systems). The following focuses on Manjaro (ArchLinux) Distribution running the KDE Plasma 5 Desktop Environment. Before getting started, the following are required.
258	258
259	259		Prerequisites
260	260
261	261		You must know the Path to your application's Binary. It will be located in the Target directory that you specified under Project Options. If you just left default settings, the Binary will be located for example for Linux x86-64 target at: \[...\]/MyProgram/lib/x86_64-linux. The file will generally not have any extension (no .exe) and will have the same name as your Project. Linux executable binaries typically either have .bin extension or no extension.
262	262
263	263		You must have sufficient rights to the file. By default, Lazarus should have created the file with your username and group as owner. If not for some reason, change ownership using chown terminal command or file manager, if available. (KDE Dolphin no longer allows sudo changes within the file manager.)
264	264
265	265		The file must be executable. Lazarus should have already set the file to be executable, but if not, change this using chmod or file manager, if available.
266	266
267	267		As inital test, make sure your application can be launched directly from the Terminal. For example, within the same directory as you application binary (e.g., MyProgram) execute:
268	268
269	269		``` bash
270	270		$ ./MyProgram
271	271		```
272	272
273	273		Make sure you can launch your application from Terminal before proceeding.
274	274
275	275		Desktop entries
276	276
277	277		To get your application to correctly launch in your Desktop Environment, you have to tell it some information by way of creating a Desktop Entry file ending in .desktop extension. This is simply a text file located in a particular directory and having specific keys. For Manjaro/ArchLinux, the following is helpful reference material:
278	278
279	279		ArchLinux Desktop Entries [3](https://wiki.archlinux.org/index.php/Desktop_Entries)
280	280
281	281		The foregoing is simply a guide, not to be taken too literally. For example, for KDE Plasma 5 on Manjaro, use of separate Path and Exec keys does NOT work. Instead, a single Exec with the application binary's full path is required. You can uncover such details and quirks by examining the existing .desktop files of other applications already installed for your particular Distro and DE.
282	282
283	283		Using the example of KDE Plasma 5 on Manjaro, proceed as follows, using hypothetical MyApp application program just created with Lazarus. Determine the location for .desktop files. For Manjaro, these were found to be at /usr/share/applications/. Now, create your .desktop file:
284	284
285	285		``` bash
286	286		$ sudo nano /usr/share/applications/myapp.desktop
287	287		```
288	288
289	289		By convention, use lowercase for the foregoing file name. Now, enter your application details (using hypothetical "MyApp" application binary).
290	290
291	291		``` bash
292	292		[Desktop Entry]
293	293		Type=Application
294	294		# Change Name to your application
295	295		Name=My Application
296	296		# Change icon to your icon - leave OFF any file extension
297	297		Icon=myappicon
298	298		Comment=My First App
299	299		# The FULL path to the folder in which the executable is run
300	300		# Change to your actual application binary's full path
301	301		Exec=/mysamplepath/Lazarus/MyApp/lib/x86_64-linux/MyApp
302	302		Terminal=false
303	303		# Sample Category - will determine where it is listed in Menu tree
304	304		Categories=Office;
305	305		```
306	306
307	307		You will be storing your icon separately, as required by your DE, so that it may be displayed in the DE's menu along with your application name. In Manjaro, icons are required to be placed at /usr/share/pixmaps. If needed, a good source for icons is available at: Open Icon Library [4](https://sourceforge.net/projects/openiconlibrary/) For KDE Plasma 5 on Manjaro, 48x48 PNGs work well. Note that you must leave .png extension off above icon reference to avoid validation errors. Now validate your Desktop Entry file:
308	308
309	309		``` bash
310	310		$ sudo desktop-file-validate /usr/share/applications/myapp.desktop
311	311		```
312	312
313	313		Correct any errors. Finally, complete installation by updating the DE's desktop database:
314	314
315	315		``` bash
316	316		$ sudo update-desktop-database
317	317		```
318	318
319	319		Your application should now be listed in KDE's menu tree and easily launched with mouse click. If you need to clean up KDE's menu (e.g., delete incorrect menu item), launch kmenuedit from Terminal or right click (if available) directly on menu item.
320	320
321	321		### See also
322	322
323	323		- [[Create snap package\|How to create an Ubuntu snap package]]
324	324		- [[Publish project on Launchpad]]
325	325
326	326		## Creating a Makefile for your Lazarus software
327	327
328	328		The following is a command line build system for a Lazarus software. This is particularly useful if you wish to create an RPM package suitable for including on GNU/Linux distributions. The comments on the files should explain what each part does.
329	329
330	330		make.sh
331	331
332	332		``` bash
333	333		# Detects and parses the architecture
334	334		ARCH=$(uname -m)
335	335
336	336		case "$ARCH" in
337	337		"i686") ARCH="i386";;
338	338		"i586") ARCH="i386";;
339	339		"i486") ARCH="i386";;
340	340		esac
341	341
342	342		echo "Target architecture: $ARCH"
343	343
344	344		# Detects and parses the OS
345	345		OS="linux"
346	346
347	347		echo "Target operating system: $OS"
348	348
349	349		# Command line to build the sofware
350	350		fpc -S2cgi -OG1 -gl -WG -vewnhi -l -Fu/usr/lib/lazarus/components/opengl/gtk2x11/ -Fi/usr/lib/lazarus/components/opengl/gtk2x11/include/ -Fu/usr/lib/lazarus/components/jpeg/ -Fu/usr/lib/lazarus/lcl/units/$ARCH-$OS/ -Fu/usr/lib/lazarus/lcl/units/$ARCH-$OS/ -Fu/usr/lib/lazarus/lcl/units/$ARCH-$OS/gtk2/ -Fu/usr/lib/lazarus/packager/units/$ARCH-$OS/ -Fu. -o./magnifier -dLCL -dLCLgtk2 magnifier.dpr
351	351		```
352	352
353	353		install.sh
354	354
355	355		``` bash
356	356		# Parses command line options. Currently supported options are:
357	357		# DESTDIR Destination root directory
358	358
359	359		DESTDIR=""
360	360
361	361		for arg; do
362	362		case $arg in
363	363		DESTDIR=*) DESTDIR=${arg#DESTDIR=};;
364	364		esac;
365	365		done
366	366
367	367		# Does the install
368	368		# "mkdir -p" is equivalent to ForceDirectories Pascal function
369	369
370	370		mkdir -p $DESTDIR/usr/share/magnifier
371	371
372	372		cp ./topleft.bmp $DESTDIR/usr/share/magnifier/
373	373		cp ./topright.bmp $DESTDIR/usr/share/magnifier/
374	374		cp ./bottomleft.bmp $DESTDIR/usr/share/magnifier/
375	375		cp ./bottomright.bmp $DESTDIR/usr/share/magnifier/
376	376		cp ./top.bmp $DESTDIR/usr/share/magnifier/
377	377		cp ./left.bmp $DESTDIR/usr/share/magnifier/
378	378		cp ./bottom.bmp $DESTDIR/usr/share/magnifier/
379	379		cp ./right.bmp $DESTDIR/usr/share/magnifier/
380	380		cp ./icon3.ico $DESTDIR/usr/share/magnifier/
381	381
382	382		mkdir -p $DESTDIR/usr/bin
383	383
384	384		cp ./magnifier $DESTDIR/usr/bin/
385	385		```
386	386
387	387		clean.sh
388	388
389	389		``` bash
390	390		rm -rf *.o
391	391		rm -rf *.ppu
392	392		rm -rf *.pas~
393	393		rm -rf *.sh~
394	394		rm -rf *.bak
395	395		rm -rf *~
396	396		rm -rf magnifier
397	397		```
398	398
399	399		uninstall.sh
400	400
401	401		``` bash
402	402		#
403	403		# Don´t use "rm -rf" in here, because you should only remove the files you created
404	404		rm -f /usr/share/magnifier/topleft.bmp
405	405		rm -f /usr/share/magnifier/topright.bmp
406	406		rm -f /usr/share/magnifier/bottomleft.bmp
407	407		rm -f /usr/share/magnifier/bottomright.bmp
408	408		rm -f /usr/share/magnifier/top.bmp
409	409		rm -f /usr/share/magnifier/left.bmp
410	410		rm -f /usr/share/magnifier/bottom.bmp
411	411		rm -f /usr/share/magnifier/right.bmp
412	412		rm -f /usr/share/magnifier/icon3.ico
413	413		rm -f /usr/share/magnifier/magnifier
414	414		rm -f /usr/bin/magnifier
415	415		rmdir /usr/share/magnifier
416	416		```
417	417
418	418		Makefile
419	419
420	420		``` bash
421	421		# Targets
422	422		# The First target is the one build when there is nothing on make command line
423	423		all:
424	424		./make.sh
425	425		clean:
426	426		./clean.sh
427	427		install:
428	428		./install.sh
429	429		uninstall:
430	430		./uninstall.sh
431	431		```
432	432
433	433		## macOS Deployment
434	434
435	435		### An Application Bundle
436	436
437	437		See [[Application Bundle]] for information on how to create an application bundle (a directory with application files that is treated by macOS as an executable).
438	438
439	439		Most macOS applications are distributed as a disk image file (.dmg extension). Normally you download or copy a program's disk image to your Mac and double-click it. This mounts the disk image and opens a window on the desktop, where you'll typically see an application bundle as described in the previous point. To install, a user simply drags the bundle to the hard drive, typically into his or the general Applications folder. Therefore, many disk images present a link to the general Applications folder for easier dragging. "Uninstalling" is by deleting the bundle.
440	440
441	441		Once the installation is complete, you eject (unmount) the mounted disk image, for example by dragging it to the trash. You can also delete the .dmg file by dragging it to the trash as well.
442	442
443	443		Your bonus point is, if the application can also run directly from the (read-only) disk image.
444	444
445	445		Here is the `app2dmg.sh` script which I use to create a .dmg file for an application bundle:
446	446
447	447		``` sh
448	448		#!/bin/sh
449	449
450	450		if [ "${1}" = "" ]
451	451		then
452	452		echo "Usage: app2dmg.sh app_name.app disk_size_in_mb"
453	453		exit
454	454		fi
455	455
456	456		if [ "${2}" = "" ]
457	457		then
458	458		echo "Usage: app2dmg.sh app_name.app disk_size_in_mb"
459	459		exit
460	460		fi
461	461
462	462		if [ ! -r "${1}" ]
463	463		then
464	464		echo "${1} is not in the current directory!"
465	465		exit
466	466		fi
467	467
468	468		APP=`echo "${1}" \| sed "s/\.app//"`
469	469		DATE=`date "+%d%m%Y"`
470	470		VOLUME="${APP}_${DATE}"
471	471
472	472		echo "Application name: ${APP}"
473	473		echo "Volume name: ${VOLUME}"
474	474
475	475		if [ -r ${APP}*.dmg.sparseimage ]
476	476		then
477	477		rm ${APP}*.dmg.sparseimage
478	478		fi
479	479
480	480		hdiutil create -size ${2}M -type SPARSE -volname "${VOLUME}" -fs HFS+ ${VOLUME}.dmg
481	481
482	482		hdiutil attach ${VOLUME}.dmg.sparseimage
483	483		cp -R ${APP}.app "/Volumes/${VOLUME}/"
484	484		cp README_FIRST.TXT "/Volumes/${VOLUME}/"
485	485		hdiutil detach -force "/Volumes/${VOLUME}"
486	486
487	487		hdiutil convert "${VOLUME}.dmg.sparseimage" -format UDBZ -o "${VOLUME}.dmg" -ov -imagekey zlib-level=9
488	488		rm ${VOLUME}*.dmg.sparseimage
489	489		```
490	490
491	491		You can also read [this guide](http://el-tramo.be/guides/fancy-dmg) for how to create a fancy disk image.
492	492
493	493		### Using Packages on macOS
494	494
495	495		The Apple `pkgbuild` and `productbuild` command line tools can produce package .pkg files or the aptly named, third party GUI [`Packages`](http://s.sudre.free.fr/Software/Packages/about.html) application which builds flat packages (cf bundle-style packages built by the same author's GUI [`Iceberg`](http://s.sudre.free.fr/Software/Iceberg.html) application.
496	496
497	497		If you absolutely require that several files are installed in different locations, then (and only then!) should you create a package file (.pkg extension) for the Apple Installer. This package file can then be moved, downloaded or emailed. Once the end user has it, they can double-click the package and the `Installer.app`, which will perform the installation, is launched.
498	498
499	499		Package files have certain advantages:
500	500
501	501		- You have control over permissions;
502	502		- Multiple files can be placed in different locations;
503	503		- You can run scripts as part of the installation process;
504	504		- A logged-in user is not needed to install a package;
505	505		- Most, if not all, Mac management systems can install Apple installer packages.
506	506
507	507		The installer .pkg file is actually a directory, as is the resulting application bundle (.app extension) that it copies to the Applications folder. To the user, .pkg and .app files look and act like ordinary files, but they're really directories whose details have been hidden from the user. You can see what's inside a .pkg or .app file by entering normal `cd` commands in a Terminal window (for example, `cd progname.app`) or by Ctrl-Clicking the file and choosing Show Package Contents from the popup menu.
508	508
509	509		To create a .dmg file, run the macOS Disk Utility (located in Applications \> Utilities). Select Images \> New \> Image from Folder and choose the folder containing your .pkg file and any other files you want to include in the disk image. In the Convert Image dialog, enter the name of the .dmg file to create, select where it should be saved, and select "compressed" as the image format. The .dmg file that Disk Utility creates is then ready for distribution.
510	510
511	511		### Installing X11 and GTK on macOS
512	512
513	513		GUI apps created with Lazarus that use the GTK widgetset require X11 and the GTK libraries to run. The [XQuartz open source project](https://www.xquartz.org) `X11.app` was shipped with Leopard 10.5 through Lion 10.7 as an optional installation. After Lion 10.7, Apple stopped providing X11 but it can still be downloaded from the XQuartz project website.
514	514
515	515		To install the GTK libraries on a user's system, you should include instructions for using [Fink](http://www.finkproject.org/) or [MacPorts](http://www.macports.org/). Do not manually package the libraries and install those in the default Fink/MacPorts locations, because then they may be overwritten in case the user decides to install one of these distributions. A good practice is to put those libraries in the application bundle itself, which requires [using the install_name_tool](http://qin.laya.com/tech_coding_help/dylib_linking.html) program. Putting them somewhere else is possible, but in most cases not conform to the Apple Guidelines as well as not what users expect. Before simply using directories common to other systems, you should carefully read the guidelines about the file system layout [File System Overview](http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPFileSystem/BPFileSystem.html).
516	516
517	517		### Code signing and Notarization
518	518
519	519		See [[Code Signing for macOS]] (required from macOS 10.7+) and [[Notarization for macOS 10.14.5+\|Notarization for macOS]] (required from macOS 10.14.5+).
520	520
521	521		Note: It is still possible not to code sign and notarise your applications if you do not mind your endusers facing scary warning dialogs from Apple - Gatekeeper can (still) be by-passed by Conctrol-Clicking on the application or right clicking on the application for the context menu, and then choosing Open and not Move to trash or Cancel. Notarization requires you to enrol in the [Apple Developer Program](https://developer.apple.com/programs/) (\$US 99 annually).
522	522
523	523		### See also
524	524
525	525		- [Apple's Software Delivery Legacy Guide](https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/SoftwareDistribution4/Introduction/Introduction.html).
526	526
527	527		- [The Luggage](https://github.com/unixorn/luggage/wiki) Uses a Makefile describing where you want each file in the package to end up on the target machines with rules that will generate a package root with appropriate permissions, copy the files into place, create a package version-stamped with the date, then wrap the package in a disk image file. This allows packages to be built in a consistent and repeatable way using source files and scripts.
528	528
529	529		- [munkipkg](https://github.com/munki/munki-pkg) is a simple tool for building packages in a consistent, repeatable manner from source files and scripts in a project directory. Files, scripts, and metadata are stored in a way that is easy to track and manage using a version control system like git.
530	530
531	531		- [[macOS PackageMaker]] - legacy - discontinued after Xcode 4.4.
532	532
533	533		## Android Deployment
534	534
535	535		(This information needs to be consolidated here and the below links adjusted)
536	536
537	537		- [[Android]]
538	538		- [[FPC JVM Android Development]]
539	539		- [[Android Programming]]
540	540
541	541		## Apple iOS Deployment
542	542
543	543		(This information needs to be consolidated here and the below links adjusted)
544	544
545	545		- [[iOS Designer]]
546	546		- [[Portal:iOS\|iOS Portal]]
547	547		- [[iPhone/iPod development]]
548	548
549	549		## Other, General Cross-Platform Deployment
550	550
551	551		### BitRock
552	552
553		-	~~<figure>~~
554		-	~~<img src="gui-newproject.png" title="\|600px" />~~
555		-	~~<figcaption>\|600px</figcaption>~~
556		-	~~</figure>~~
	553	+	![](/wiki-images/2/28/Gui-newproject.png)
557	554
558	555		[[BitRockInstallBuilder\|Bitrock]] (website www.bitrock.com) make an installer that will deploy to Windows, Mac OS and many flavors of Linux. If your application is open-source, they will give you a full license to download and use their 'InstallBuilder' application.[[http://installbuilder.bitrock.com/open-source-licenses.html Application form link]]. Commercial application licenses are available.
559	556
560	557		### fpGUI Installer
561	558
562	559		This is a cross-platform CLI and GUI installer. It is loosely based on the concept of the Loki Installer (implemented in the C programming language) created by [Loki Games](http://www.lokigames.com/). The difference being that fpGUI Installer is implemented from scratch using Object Pascal and the fpGUI Toolkit for the GUI parts. This installer is still under active development, but to date no public release has been made. A public release is planned though. No official name has been given to this project either - thus the not ideal "fpGUI Installer" name.
563	560
564	561		Here is a screenshot of fpGUI Installer replacing the original Kylix 3 installer: ![fpGUI Installer\\|400px](/wiki-images/b/b5/Fpgui_installer.png)
565	562
566	563		Features:
567	564
568	565		- Installer setup is done via an easily managed XML file. A GUI front-end is used to edit the XML, but it can be done by hand too.
569	566		- CD-ROM or Downloadable installers. The difference being that the CD-ROM installer is normally unpacked and multiple languages, tools etc are included. A Downloadable installer is a single file download and normally packaged for a specific language.
570	567		- Automatic icon shortcut generation
571	568		- No external libraries or runtime environments required. The idea is that a installer must not have system requirements (eg: a JVM or the Qt library etc), hence fpGUI toolkit was used for the GUI installer, because it talks directly to GDI or X11.
572	569		- Command Line Installer and GUI Installer included as standard.
573	570		- Support uninstall as well
574	571		- fpGUI Installer has been tested on Windows (Win98 thru Win7), Linux (various distros), FreeBSD and OpenSolaris.
575	572		- Supports 32-bit and 64-bit setup files.
576	573		- Group installer mode: The installer can present a user friendly interface to install multiple other projects.
577	574		- Customisable graphics banner and UI theme.
578	575
579	576		### InstallJammer
580	577
581	578		InstallJammer is a multiplatform GUI installer designed to be completely cross-platform and function on Windows and most all versions of UNIX.
582	579
583	580		InstallJammer features a very powerful install builder with support for multiple themes and a high level of configurability for installers. Installers are built as single executable files for easy distribution over the web and handle installing everything you need for your application in a simple, cross-platform way.
584	581
585	582		- Active development of InstallJammer has been discontinued. The source is available for all versions and will always remain so, but your efforts might be better spent on an installer that is active in its development.
586	583		- Download: <https://sourceforge.net/projects/installjammer/files/InstallJammer/>
587	584		- Documentation: <http://installjammer.com/docs/>
588	585
589	586		### CMake/CPack
590	587
591	588		CMake is a multiplatform build system that manages the compilation, linking, testing, and setup creation process. It is mainly intended for C/C++ software development, but can also be used for creating setups for Lazarus/FPC projects. The part of CMake that creates the setups is called CPack and is actually a front-end for other software packages that do the real work. In an FPC context, you would write a CMakeLists.txt file that contains lists of files to be installed and then have CPack call NSIS/WiX/... to perform the actual work.
592	589
593	590		Features:
594	591
595	592		- Windows (32+64 Bit), Linux, macOS support
596	593		- Works with all important back-ends (NSIS, WiX, DEB...)
597	594		- Just one text file CMakeLists.txt needs to be mainained for all target platforms
598	595		- Multi-platform setups can be created with minimal work
599	596		- Download: <http://www.cmake.org/>
600	597
601	598		Using CMake/CPack makes most sense if you have a mixed-language project with Pascal and C/C++ parts that all go into one installer, and you need a platform-independent solution for both parts. If you have a pure FPC project, the overhead might be too much for you.
602	599
603	600		---
604	601		From the Free Pascal wiki, page "Deploying Your Application", as it stood on 2023-11-20 after a change by Chronos, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).

Back to history