Compiling with CMake (OpenXcom) - Revision history

Hobbes: Undo revision 126414 by Hobbes (talk)

2026-03-10T15:01:09Z

Undo revision 126414 by Hobbes (talk)

← Older revision		Revision as of 15:01, 10 March 2026
Line 1:		Line 1:
	#~~REDIRECT~~ [[OpenXcom]]		CMake is a meta-build system. It doesn't build the code itself. Instead, it autogenerates files for other build systems, like Make or Visual Studio. It is an excellent tool for maintaining consistent build environments across multiple operating systems.

			__TOC__

			== Before building ==
			In addition to the OpenXcom [[Compiling (OpenXcom)#Dependencies \|dependencies]], you will need CMake version 2.8.0 or later.

			CMake can be used to build OpenXcom with differents tools. So far only the Makefile and Visual Studio have been tried. Other Generators (Xcode/Code blocks, ...) might work, but if you choose to use them, we currently have no way to make sure that they work. If broken, patches are welcome to make them work.

			Note : Once a project has been generated, you don't need to regenerate it after updating the source. CMake will automatically check for modifications and regenerate the project for you.

			Source dir/build dir: CMake allows you to separate the source directory (where the source resides) from the build directory (where the project is generated). This allows you to always have a clean source directory (no clutter left from builds). The source and build directories can be the same, but it's generally recommended to separate them. The standard name for the build directory is "build", which you must create yourself under the top level OpenXcom directory (where the README.md file is).


			== Generate a build project ==

			'''Using CMake GUI tool'''
			*Launch the CMake configuration tools. First specify the path to the OpenXcom source tree.
			*Then specify where the OpenXcom project should be generated (e.g. the "build" directory that you created).
			*Click on configure. The first time, CMake will ask you which kind of build tool you wish to use.
			*Now CMake will analyze your system and once finished, you will be presented with a list of options. If all is fine for you, then click on generate.

			'''Using CMake interactive command line tools'''

			ccmake is a command line tool which allows you to configure the build interactively. You can launch it with:
			mkdir -p build
			cmake -B build -G 'Generator name' .
			Generator name, is the name of the build system you wish to use. You can see possible values with:
			cmake --help
			If omitted, cmake will default to 'Unix Makefile'. Note that this needed only the first time you generate the project.

			As with the GUI, tweak the options as needed and then configure the project before generating it.


			'''Using CMake command line tools'''
			mkdir -p build
			cmake -B build -G 'Generator name' -DOPTION_NAME=OPTION_VALUE ..
			You can check options value with:
			cmake -L
			To change the value of an option:
			cmake -DOPTION_NAME=OPTION_VALUE ..
			For example:
			cmake -B build -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=$HOME/bin/openxcom.inst .

			Once the project is generated, you can use it as you would have done without using CMake.


			== End-to-end example ==

			This will get you up and running from scratch to a fully functional installation. This example is written with Linux users in mind, but can be adapted easily for Windows or OSX. It shows an alternative way of cd'ing into the build dir and running the compilation commands from there.

			git clone git@github.com:OpenXcom/OpenXcom.git openxcom
			OR "git clone https://github.com/OpenXcom/OpenXcom.git openxcom" if the above doesn't work for whatever reason
			{copy XCOM1 assets into openxcom/bin/UFO and XCOM2 assets into openxcom/bin/TFTD, do not forget to apply the [http://openxcom.org/downloads-extras patchfiles]}
			mkdir openxcom/build
			cd openxcom/build
			cmake ..
			ccmake ..
			{set CMAKE_BUILD_TYPE to Release (or Debug if you want useful stack traces, but that will slow the game /way/ down)}
			{set CMAKE_INSTALL_PREFIX to /home/yourusername/bin/OpenXcom (or whatever)}
			{configure, generate, and exit}
			make -j3
			make install

			''' Automated patching and compiling '''

			It can also be fully automated, in case you want fast compilation e. g. for testing/using nightlies on a regular basis:

			git clone https://github.com/SupSuper/OpenXcom.git openxcom
			cp -r /path/to/UFO_vanilla_with_patch_files_applied/* openxcom/bin/UFO/
			mkdir openxcom/build
			cd openxcom/build
			cmake -DCMAKE_BUILD_TYPE=Release ..
			make -j10
			sudo make install

			This version downloads the sources, then copies prepared vanilla-files (should already include the [http://openxcom.org/downloads-extras patchfiles]) to the right place. One could as well decompress a prepared 7zip-archive like <code>7za e /path/to/UFO_vanilla_with_patch_files_applied.7z -oopenxcom/bin/UFO/ -y</code>. After that, it compiles automatically as »Release«, also speeding up the process a bit, by using 10 jobs parallel, instead of just 3. As OpenXcom usually is installed automatically in a folder, where users don't have write-access (unless you also change the <code>CMAKE_INSTALL_PREFIX</code> variable accordingly, see <code>-DCMAKE_BUILD_TYPE=Release</code>-line), the <code>sudo</code> before the last command makes sure, a legitimation is requested (if the script is not started already with <code>sudo</code>). If you let it be installed somewhere you have the write permissions, with the mentioned prepared vanilla- and patch-files somewhere laying around, you won't even need the sudo, so you don't need to enter anything for a compilation run. Saving this example adjusted to your need, e. g. as <code>compileopenxcom.sh</code> and making it executable, you have an installation-skript, which needs very little attention. This can save a lot of time, if you compile nightlies more often.

			Then there are two ways for getting a well playable/startable game:

			''' Starting script '''

			Create an executable shell script in your <code>$HOME/bin</code> directory (ensure it is in your PATH) named <code>openxcom</code> with the contents:
			#!/bin/sh
			"$HOME/bin/OpenXcom/bin/openxcom" -data "$HOME/bin/OpenXcom/share/openxcom/data"

			now just run <code>openxcom</code> to play. : )

			''' Desktop-icon '''

			On Ubuntu-Systems, or in general, using GNOME, you also might want to create a <code>*.desktop</code>-file, which shows a nice icon and starts your OpenXcom as well as that starting-script above. An example would be:

			[Desktop Entry]
			Version=1.0
			Type=Application
			Name=OpenXcom
			Comment=Open-source clone of UFO: Enemy Unknown
			Exec=/binary_path_to/openxcom
			Terminal=false
			Icon=/path_to_openxcom_basefolder/common/openxcom.png
			Categories=Game;StrategyGame;

			You can save it as <code>openxcom.desktop</code> either somewhere, you want to start it from (e. g. your desktop) or put it in the suitable folder, where GNOME-Search will find it, e. g. <code>~/.local/share/applications</code>, if you want it only for your own user, or <code>/usr/share/applications</code>, if it is meant for every user. It ''may'' be necessary, to make this file executable.

			[[Category:OpenXcom]]

Hobbes: Removed protection from "Compiling with CMake (OpenXcom)"

2026-03-10T14:47:33Z

Removed protection from "Compiling with CMake (OpenXcom)"

← Older revision	Revision as of 14:47, 10 March 2026
(No difference)

Hobbes: Protected "Compiling with CMake (OpenXcom)" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

2026-03-10T13:56:47Z

Protected "Compiling with CMake (OpenXcom)" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

← Older revision	Revision as of 13:56, 10 March 2026
(No difference)

Hobbes: Redirected page to OpenXcom

2026-03-10T13:56:07Z

Redirected page to OpenXcom

← Older revision		Revision as of 13:56, 10 March 2026
Line 1:		Line 1:
	CMake is a meta-build system. It doesn't build the code itself. Instead, it autogenerates files for other build systems, like Make or Visual Studio. It is an excellent tool for maintaining consistent build environments across multiple operating systems.		#REDIRECT [[OpenXcom]]

	~~__TOC__~~

	~~== Before building ==~~
	~~In addition to the OpenXcom [[Compiling (OpenXcom)#Dependencies \|dependencies]], you will need CMake version 2.8.0 or later.~~

	CMake can be used to build OpenXcom with differents tools. So far only the Makefile and Visual Studio have been tried. Other Generators (Xcode/Code blocks, ...) might work, but if you choose to use them, we currently have no way to make sure that they work. If broken, patches are welcome to make them work.

	~~Note : Once a project has been generated, you don't need to regenerate it after updating the source. CMake will automatically check for modifications and regenerate the project for you.~~

	Source dir/build dir: CMake allows you to separate the source directory (where the source resides) from the build directory (where the project is generated). This allows you to always have a clean source directory (no clutter left from builds). The source and build directories can be the same, but it's generally recommended to separate them. The standard name for the build directory is "build", which you must create yourself under the top level OpenXcom directory (where the README.md file is).


	~~== Generate a build project ==~~

	~~'''Using CMake GUI tool'''~~
	*Launch the CMake configuration tools. First specify the path to the OpenXcom source tree.
	*Then specify where the OpenXcom project should be generated (e.g. the "build" directory that you created).
	*Click on configure. The first time, CMake will ask you which kind of build tool you wish to use.
	*Now CMake will analyze your system and once finished, you will be presented with a list of options. If all is fine for you, then click on generate.

	~~'''Using CMake interactive command line tools'''~~

	~~ccmake is a command line tool which allows you to configure the build interactively. You can launch it with:~~
	~~mkdir -p build~~
	~~cmake -B build -G 'Generator name' .~~
	~~Generator name, is the name of the build system you wish to use. You can see possible values with:~~
	~~cmake --help~~
	~~If omitted, cmake will default to 'Unix Makefile'. Note that this needed only the first time you generate the project.~~

	~~As with the GUI, tweak the options as needed and then configure the project before generating it.~~


	~~'''Using CMake command line tools'''~~
	~~mkdir -p build~~
	~~cmake -B build -G 'Generator name' -DOPTION_NAME=OPTION_VALUE ..~~
	~~You can check options value with:~~
	~~cmake -L~~
	~~To change the value of an option:~~
	~~cmake -DOPTION_NAME=OPTION_VALUE ..~~
	~~For example:~~
	~~cmake -B build -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=$HOME/bin/openxcom.inst .~~

	~~Once the project is generated, you can use it as you would have done without using CMake.~~


	~~== End-to-end example ==~~

	This will get you up and running from scratch to a fully functional installation. This example is written with Linux users in mind, but can be adapted easily for Windows or OSX. It shows an alternative way of cd'ing into the build dir and running the compilation commands from there.

	~~git clone git@github.com:OpenXcom/OpenXcom.git openxcom~~
	~~OR "git clone https://github.com/OpenXcom/OpenXcom.git openxcom" if the above doesn't work for whatever reason~~
	~~{copy XCOM1 assets into openxcom/bin/UFO and XCOM2 assets into openxcom/bin/TFTD, do not forget to apply the [http://openxcom.org/downloads-extras patchfiles]}~~
	~~mkdir openxcom/build~~
	~~cd openxcom/build~~
	~~cmake ..~~
	~~ccmake ..~~
	~~{set CMAKE_BUILD_TYPE to Release (or Debug if you want useful stack traces, but that will slow the game /way/ down)}~~
	~~{set CMAKE_INSTALL_PREFIX to /home/yourusername/bin/OpenXcom (or whatever)}~~
	~~{configure, generate, and exit}~~
	~~make -j3~~
	~~make install~~

	~~''' Automated patching and compiling '''~~

	~~It can also be fully automated, in case you want fast compilation e. g. for testing/using nightlies on a regular basis:~~

	~~git clone https://github.com/SupSuper/OpenXcom.git openxcom~~
	~~cp -r /path/to/UFO_vanilla_with_patch_files_applied/* openxcom/bin/UFO/~~
	~~mkdir openxcom/build~~
	~~cd openxcom/build~~
	~~cmake -DCMAKE_BUILD_TYPE=Release ..~~
	~~make -j10~~
	~~sudo make install~~

	This version downloads the sources, then copies prepared vanilla-files (should already include the [http://openxcom.org/downloads-extras patchfiles]) to the right place. One could as well decompress a prepared 7zip-archive like <code>7za e /path/to/UFO_vanilla_with_patch_files_applied.7z -oopenxcom/bin/UFO/ -y</code>. After that, it compiles automatically as »Release«, also speeding up the process a bit, by using 10 jobs parallel, instead of just 3. As OpenXcom usually is installed automatically in a folder, where users don't have write-access (unless you also change the <code>CMAKE_INSTALL_PREFIX</code> variable accordingly, see <code>-DCMAKE_BUILD_TYPE=Release</code>-line), the <code>sudo</code> before the last command makes sure, a legitimation is requested (if the script is not started already with <code>sudo</code>). If you let it be installed somewhere you have the write permissions, with the mentioned prepared vanilla- and patch-files somewhere laying around, you won't even need the sudo, so you don't need to enter anything for a compilation run. Saving this example adjusted to your need, e. g. as <code>compileopenxcom.sh</code> and making it executable, you have an installation-skript, which needs very little attention. This can save a lot of time, if you compile nightlies more often.

	~~Then there are two ways for getting a well playable/startable game:~~

	~~''' Starting script '''~~

	~~Create an executable shell script in your <code>$HOME/bin</code> directory (ensure it is in your PATH) named <code>openxcom</code> with the contents:~~
	#~~!/bin/sh~~
	~~"$HOME/bin/OpenXcom/bin/openxcom" -data "$HOME/bin/OpenXcom/share/openxcom/data"~~

	~~now just run <code>openxcom</code> to play. : )~~

	~~''' Desktop-icon '''~~

	On Ubuntu-Systems, or in general, using GNOME, you also might want to create a <code>*.desktop</code>-file, which shows a nice icon and starts your OpenXcom as well as that starting-script above. An example would be:

	~~[Desktop Entry]~~
	~~Version=1.0~~
	~~Type=Application~~
	~~Name=OpenXcom~~
	~~Comment=Open-source clone of UFO: Enemy Unknown~~
	~~Exec=/binary_path_to/openxcom~~
	~~Terminal=false~~
	~~Icon=/path_to_openxcom_basefolder/common/openxcom.png~~
	~~Categories=Game;StrategyGame;~~

	You can save it as <code>openxcom.desktop</code> either somewhere, you want to start it from (e. g. your desktop) or put it in the suitable folder, where GNOME-Search will find it, e. g. <code>~/.local/share/applications</code>, if you want it only for your own user, or <code>/usr/share/applications</code>, if it is meant for every user. It ''may'' be necessary, to make this file executable.

	[[~~Category:~~OpenXcom]]

Uqs at 15:31, 10 November 2020

2020-11-10T15:31:44Z

← Older revision		Revision as of 15:31, 10 November 2020
Line 24:		Line 24:

	ccmake is a command line tool which allows you to configure the build interactively. You can launch it with:		ccmake is a command line tool which allows you to configure the build interactively. You can launch it with:
	cd build		mkdir -p build
	~~ccmake~~ -G 'Generator name' ..		cmake -B build -G 'Generator name' .
	Generator name, is the name of the build system you wish to use. You can see possible values with:		Generator name, is the name of the build system you wish to use. You can see possible values with:
	cmake help		cmake --help
	If omitted, cmake will default to 'Unix Makefile'. Note that this needed only the first time you generate the project.		If omitted, cmake will default to 'Unix Makefile'. Note that this needed only the first time you generate the project.

Line 34:		Line 34:

	'''Using CMake command line tools'''		'''Using CMake command line tools'''
	cd build		mkdir -p build
	cmake -G 'Generator name' -DOPTION_NAME=OPTION_VALUE ..		cmake -B build -G 'Generator name' -DOPTION_NAME=OPTION_VALUE ..
	You can check options value with:		You can check options value with:
	cmake -L		cmake -L
Line 41:		Line 41:
	cmake -DOPTION_NAME=OPTION_VALUE ..		cmake -DOPTION_NAME=OPTION_VALUE ..
	For example:		For example:
	cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=$HOME/bin/openxcom.inst ..		cmake -B build -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=$HOME/bin/openxcom.inst .

	Once the project is generated, you can use it as you would have done without using CMake.		Once the project is generated, you can use it as you would have done without using CMake.
Line 48:		Line 48:
	== End-to-end example ==		== End-to-end example ==

	This will get you up and running from scratch to a fully functional installation. This example is written with Linux users in mind, but can be adapted easily for Windows or OSX.		This will get you up and running from scratch to a fully functional installation. This example is written with Linux users in mind, but can be adapted easily for Windows or OSX. It shows an alternative way of cd'ing into the build dir and running the compilation commands from there.

	git clone git@github.com:~~SupSuper~~/OpenXcom.git openxcom		git clone git@github.com:OpenXcom/OpenXcom.git openxcom
	OR "git clone https://github.com/~~SupSuper~~/OpenXcom.git openxcom" if the above doesn't work for whatever reason		OR "git clone https://github.com/OpenXcom/OpenXcom.git openxcom" if the above doesn't work for whatever reason
	{copy XCOM1 assets into openxcom/bin/UFO and XCOM2 assets into openxcom/bin/TFTD, do not forget to apply the [http://openxcom.org/downloads-extras patchfiles]}		{copy XCOM1 assets into openxcom/bin/UFO and XCOM2 assets into openxcom/bin/TFTD, do not forget to apply the [http://openxcom.org/downloads-extras patchfiles]}
	mkdir openxcom/build		mkdir openxcom/build

7Saturn: /* End-to-end example */

2015-05-24T10:58:27Z

End-to-end example

← Older revision		Revision as of 10:58, 24 May 2015
Line 81:		Line 81:
	''' Starting script '''		''' Starting script '''

	Create an executable shell script in your $HOME/bin directory (ensure it is in your PATH) named openxcom with the contents:		Create an executable shell script in your <code>$HOME/bin</code> directory (ensure it is in your PATH) named <code>openxcom</code> with the contents:
	#!/bin/sh		#!/bin/sh
	"$HOME/bin/OpenXcom/bin/openxcom" -data "$HOME/bin/OpenXcom/share/openxcom/data"		"$HOME/bin/OpenXcom/bin/openxcom" -data "$HOME/bin/OpenXcom/share/openxcom/data"

7Saturn: /* End-to-end example */

2015-05-24T10:57:14Z

End-to-end example

← Older revision		Revision as of 10:57, 24 May 2015
Line 75:		Line 75:
	sudo make install		sudo make install

	This version downloads the sources, then copies prepared vanilla-files (should already include the [http://openxcom.org/downloads-extras patchfiles]) to the right place. One could as well decompress a prepared 7zip-archive like <code>7za e /path/to/UFO_vanilla_with_patch_files_applied.7z -oopenxcom/bin/UFO/ -y</code>. After that, it compiles automatically as »Release«, also speeding up the process a bit, by using 10 jobs parallel, instead of just 3. As OpenXcom usually is installed automatically in a folder, where users don't have write-access (unless you also change the <code>CMAKE_INSTALL_PREFIX</code> variable accordingly, see <code>-DCMAKE_BUILD_TYPE=Release</code>-line), the <code>sudo</code> before the last command makes sure, a legitimation is requested (if the script is not started already with <code>sudo</code>). If you let it be installed somewhere you have the write permissions, with the mentioned prepared ~~7zip~~-~~file~~ somewhere laying around, you won't even need the sudo, so you don't need to enter anything for a compilation run. Saving this example adjusted to your need, e. g. as <code>compileopenxcom.sh</code> and making it executable, you have an installation-skript, which needs very little attention. This can save a lot of time, if you compile nightlies more often.		This version downloads the sources, then copies prepared vanilla-files (should already include the [http://openxcom.org/downloads-extras patchfiles]) to the right place. One could as well decompress a prepared 7zip-archive like <code>7za e /path/to/UFO_vanilla_with_patch_files_applied.7z -oopenxcom/bin/UFO/ -y</code>. After that, it compiles automatically as »Release«, also speeding up the process a bit, by using 10 jobs parallel, instead of just 3. As OpenXcom usually is installed automatically in a folder, where users don't have write-access (unless you also change the <code>CMAKE_INSTALL_PREFIX</code> variable accordingly, see <code>-DCMAKE_BUILD_TYPE=Release</code>-line), the <code>sudo</code> before the last command makes sure, a legitimation is requested (if the script is not started already with <code>sudo</code>). If you let it be installed somewhere you have the write permissions, with the mentioned prepared vanilla- and patch-files somewhere laying around, you won't even need the sudo, so you don't need to enter anything for a compilation run. Saving this example adjusted to your need, e. g. as <code>compileopenxcom.sh</code> and making it executable, you have an installation-skript, which needs very little attention. This can save a lot of time, if you compile nightlies more often.

	Then there are two ways for getting a well playable/startable game:		Then there are two ways for getting a well playable/startable game:

7Saturn: /* End-to-end example */

2015-05-24T10:55:37Z

End-to-end example

← Older revision		Revision as of 10:55, 24 May 2015
Line 68:		Line 68:

	git clone https://github.com/SupSuper/OpenXcom.git openxcom		git clone https://github.com/SupSuper/OpenXcom.git openxcom
	~~7za e~~ /path/to/UFO_vanilla_with_patch_files_applied~~.7z -oopenxcom~~/bin/UFO/ -y		cp -r /path/to/UFO_vanilla_with_patch_files_applied/* openxcom/bin/UFO/
	mkdir openxcom/build		mkdir openxcom/build
	cd openxcom/build		cd openxcom/build
Line 75:		Line 75:
	sudo make install		sudo make install

	This version downloads the sources, then ~~decompresses a~~ prepared ~~7zip-file, containing the~~ vanilla-files~~, including~~ the [http://openxcom.org/downloads-extras patchfiles]. After that, it compiles automatically as »Release«, also speeding up the process a bit, by using 10 jobs parallel, instead of just 3. As OpenXcom usually is installed automatically in a folder, where users don't have write-access (unless you also change the <code>CMAKE_INSTALL_PREFIX</code> variable accordingly, see <code>-DCMAKE_BUILD_TYPE=Release</code>-line), the <code>sudo</code> before the last command makes sure, a legitimation is requested (if the script is not started already with <code>sudo</code>). If you let it be installed somewhere you have the write permissions, with the mentioned prepared 7zip-file somewhere laying around, you won't even need the sudo, so you don't need to enter anything for a compilation run. Saving this example adjusted to your need, e. g. as <code>compileopenxcom.sh</code> and making it executable, you have an installation-skript, which needs very little attention. This can save a lot of time, if you compile nightlies more often.		This version downloads the sources, then copies prepared vanilla-files (should already include the [http://openxcom.org/downloads-extras patchfiles]) to the right place. One could as well decompress a prepared 7zip-archive like <code>7za e /path/to/UFO_vanilla_with_patch_files_applied.7z -oopenxcom/bin/UFO/ -y</code>. After that, it compiles automatically as »Release«, also speeding up the process a bit, by using 10 jobs parallel, instead of just 3. As OpenXcom usually is installed automatically in a folder, where users don't have write-access (unless you also change the <code>CMAKE_INSTALL_PREFIX</code> variable accordingly, see <code>-DCMAKE_BUILD_TYPE=Release</code>-line), the <code>sudo</code> before the last command makes sure, a legitimation is requested (if the script is not started already with <code>sudo</code>). If you let it be installed somewhere you have the write permissions, with the mentioned prepared 7zip-file somewhere laying around, you won't even need the sudo, so you don't need to enter anything for a compilation run. Saving this example adjusted to your need, e. g. as <code>compileopenxcom.sh</code> and making it executable, you have an installation-skript, which needs very little attention. This can save a lot of time, if you compile nightlies more often.

	Then there are two ways for getting a well playable/startable game:		Then there are two ways for getting a well playable/startable game:

7Saturn: /* End-to-end example */

2015-05-24T00:18:46Z

End-to-end example

← Older revision		Revision as of 00:18, 24 May 2015
Line 62:		Line 62:
	make -j3		make -j3
	make install		make install

			''' Automated patching and compiling '''

	It can also be fully automated, in case you want fast compilation e. g. for testing/using nightlies on a regular basis:		It can also be fully automated, in case you want fast compilation e. g. for testing/using nightlies on a regular basis:

7Saturn: /* End-to-end example */

2015-05-24T00:15:24Z

End-to-end example

← Older revision		Revision as of 00:15, 24 May 2015
Line 99:		Line 99:
	Categories=Game;StrategyGame;		Categories=Game;StrategyGame;

	You can ~~either~~ save it somewhere, you want to start it from (e. g. your desktop) or put it in the suitable folder, where GNOME-Search will find it, e. g. <code>~/.local/share/applications</code>, if you want it only for your own user, or <code>/usr/share/applications</code>, if it is meant for every user. It ''may'' be necessary, to make this file executable.		You can save it as <code>openxcom.desktop</code> either somewhere, you want to start it from (e. g. your desktop) or put it in the suitable folder, where GNOME-Search will find it, e. g. <code>~/.local/share/applications</code>, if you want it only for your own user, or <code>/usr/share/applications</code>, if it is meant for every user. It ''may'' be necessary, to make this file executable.

	[[Category:OpenXcom]]		[[Category:OpenXcom]]