Version 55 (modified by historic_bruno, 12 years ago) ( diff )

--

Summary

Parts of our build and deployment environment are currently beeing changed. The main goal behind this is being able to easily create deployable packages/bundles for OSX. This Page should be a work in progress and its purpose is to document the overall design and the different tasks required to implement it. The idea is that people involved in these tasks discuss all topics related to that and document the decisions here. Once we all have the same idea about the solution we aim for, we can assign the different tasks to different people and complete them more efficiently.

A good place for discussions is this thread in the forums.


Overview current design

update-workspaces.sh / update-workspaces.bat:

The sh-script on Linux/*nix/OSX runs the compilation of some external dependencies and also premake. On Windows the batchfile only executes premake because most of the dependencies are precompiled.

For release packaging, update-workspaces.sh can be used to set compile-time, absolute paths used by the game (to override defaults):

  • --bindir=/path/to/bin sets the location of the pyrogenesis executable (eg. /usr/bin or /opt/0ad/system). Defines the INSTALLED_BINDIR preprocessor directive.
  • --libdir=/path/to/lib sets the location of the bundled libraries (eg. /usr/lib). Defines the INSTALLED_LIBDIR preprocessor directive.
  • --datadir=/path/to/data sets the location of the game's data (e.g. /usr/share/0ad/data, /usr/local/share/0ad/data, or /opt/0ad/data). Defines the INSTALLED_DATADIR preprocessor directive.

Premake

Premake creates our workspaces (also called solutions or projects) for the different platforms. Currently we support Makefiles, VisualStudio (2005, 2008, 2010), Xcode3, Codeblocks.

Workspaces

The workspaces are used for building the code on different platform and also for development with different programs (IDE's).

Deployment

For (alpha-)releases we make a special deployment for various reasons. The main reason is that we want to make it easier and more convenient for the user. Everything is precompiled and distributed in appropriate containers for the different operating systems and platforms (e.g. .deb files for debian based linux systems and .exe files for windows etc.).


Future design

Overview

Some basic design decisions

  • In the first place we stick to Premake. If someone offers a working solution with other tools like CMake, we are open to change that decision.
  • Sticking to Premake means we can't manually create workspaces
  • We separate the external libraries from the game's code and data in the repository
  • The libraries are split into separate directories per operating system and architecture
  • Developers will have to make a separate checkout to get the right libraries for their system
  • Updateworkspaces checks if the libraries are present and up to date to avoid problems with outdated libraries
  • Supported platforms are Linux-source (no precompiled libraries in the repository), Macosx-x64 and Windows-x86.
  • We don't use special "subversion tricks" like externals definitions and instead keep separate identical copies of libraries if necessary. Storage isn't a problem and we don't update the libraries often. Other arguments brought up by Philip: "... it'll probably confuse Trac and it'll probably make mirroring/migrating to Git harder".

Graphical overview of interaction between different components (future-version)

http://trac.wildfiregames.com/attachment/wiki/BuildAndDeploymentEnvironment/future-build-environment-overview.png

The repository structure

.
|-- art
|-- audio
|-- libraries
|   `-- trunk
|       |-- linux-source
|       |   |-- libA
|       |   |   |-- include
|       |   |   `-- lib
|       |   `-- libB
|       |       |-- build.sh
|       |       |-- include
|       |       |-- lib
|       |       `-- src
|       |-- macosx-x64
|       |   |-- libA
|       |   |   |-- include
|       |   |   `-- lib
|       |   `-- libB
|       |       |-- build.sh
|       |       |-- include
|       |       |-- lib
|       |       `-- src
|       `-- windows-x86
|           |-- libA
|           |   |-- include
|           |   `-- lib
|           `-- libB
|               |-- include
|               `-- lib
`-- ps
    `-- trunk
        |-- build
        |   |-- premake
        |   `-- workspaces
        |       `-- update-workspaces.sh
        `-- source

Checking out the code

Developers will have to do an additional checkout to compile 0ad.

This is still the same command to get the source and data:
svn co http://svn.wildfiregames.com/public/ps/trunk/ 0ad

In addition to that, it will be required to get the right libraries for your system (of course replacing "windows-x86" with your platform):
svn co http://svn.wildfiregames.com/public/libraries/trunk/windows-x86 0ad/libraries

Updateworkspaces

Updateworkspaces must check if the library is present and up to date. If not, it should stop and display an error. This check could work with a manually updated file in the source-tree containing the current revisions for library-directories.


Realease, packaging and deployment

The current release process is documented in ReleaseProcess. Philip does that, except not the PPA packages or the Gentoo ebuilds. Ricotz creates the Ubuntu packages in an unknown way and other(unknown) people do it for Gentoo and the other distros.

Some information about OS-specific aspects of the packages...

Where to place which files

NOTE: This is just a draft.

Discussion about the Windows specific paths can be found in this thread.

VariableDefault
XDG_CACHE_HOME~/.cache
XDG_CONFIG_HOME~/.config
XDG_DATA_HOME~/.local/share

For release packaging, update-workspaces.sh can be used to set compile-time, absolute paths used by the game (to override defaults). It should now offer a parameter for each path in the table below and not just for bindir, libdir and datadir (to be decided for each of those three if they should be replaced or kept):

  • --bindir=/path/to/bin sets the location of the pyrogenesis executable (eg. /usr/bin or /opt/0ad/system). Defines the INSTALLED_BINDIR preprocessor directive.
  • --libdir=/path/to/lib sets the location of the bundled libraries (eg. /usr/lib). Defines the INSTALLED_LIBDIR preprocessor directive.
  • --datadir=/path/to/data sets the location of the game's data (e.g. /usr/share/0ad/data, /usr/local/share/0ad/data, or /opt/0ad/data). Defines the INSTALLED_DATADIR preprocessor directive.
  • ... See the list below

The default Atlas config dir (or file) is specified in source/tools/atlas/AtlasUI/Misc/DLLInterface.cpp and does not adhere to the values in Paths.cpp or the basedir-spec (Note #868)

NameReadonlyDescriptionPath WindowsPath LinuxPath MacDetermined by/Set where?
Game data rootYData-Directory for static game datarelative to EXEINSTALLED_DATADIR or relative to binary[BundlePath]/Contents/Resources/data or relative to binarym_rdata in Paths.cpp
User data rootNRoot-Directory for data the user creates in-game (savegames, screenshots etc...)My Documents\My Games\0ad$XDG_DATA_HOME/0ad~/Library/Application\ Support/0ad/datam_Data in Paths.cpp
Savegame directoryNDirectory where savegames are saved to and loaded fromMy Documents\My Games\0ad\saves$XDG_DATA_HOME/0ad/saves~/Library/Application\ Support/0ad/data/savesAs [User data root]\saves in GameSetup.cpp InitVFS
screenshot directoryNDirectory where screenshots are saved by the gameMy Documents\My Games\0ad\screenshots$XDG_DATA_HOME/0ad/screenshots~/Library/Application\ Support/0ad/data/screenshotsAs [User data root]\screenshots in GameSetup.cpp InitVFS
Default configYDefault config-file which is readonlyrelative to EXEINSTALLED_DATADIR/config or relative to binary[BundlePath]/Contents/Resources/data/config or relative to binaryAs [Game data root]\config in GameSetup.cpp IniVFS
UserconfigNContains user specific configuration settings%appdata%\0ad\config$XDG_CONFIG_HOME/0ad/config~/Library/Application\ Support/0ad/configm_config in Paths.cpp
LogsNContains logs created by the game%appdata%\0ad\logs$XDG_CONFIG_HOME/0ad/logs~/Library/Application\ Support/0ad/logsm_logs in Paths.cpp
CacheNCache directory%localappdata%\0ad\cache$XDG_CACHE_HOME/0ad~/Library/Caches/0adm_cache in Paths.cpp
User modNUser mod directory, where e.g. Atlas should save mapsMy Documents\My Games\0ad\mods\user$XDG_DATA_HOME/0ad/mods/user~/Library/Application\ Support/0ad/mods/userNot implemented yet
ModsYOther mods added by the userMy Documents\My Games\0ad\mods$XDG_DATA_HOME/0ad/mods~/Library/Application\ Support/0ad/modsNot implemented yet

Open tasks

1. Change how the game handles default search paths

Assigned: Yves

Each OS should have its default behaviour that should make sense for that OS (see the table above). For Windows and Linux that's already quite good, but OSX requires improvements.

It should be distinguished between three different situations.

  1. The current situation in development where the pyrogenesis binary is in 0ad/binaries/system, data is in 0ad/binaries/data etc...
  2. The situation when everything is in a bundle and the directories are organized as described in "Where to place which files?" in this article.
  3. Special situations where the users wants to use customized directories. It should be sufficient to solve this with preprocessor directives because if anyone want's to change it, it's either an advanced user or package maker anyway and generally there should be no need to change it. Each defined location in the table above should be customizable with one dedicated preprocessor directive.

Documentation to be updated:

2. Adjust the build-system and documentation for a separate library directory

Unassigned

This task involves:

  1. Changing the repository structure as listed above
  2. Check if the libraries are present and up-to-date in update-workspaces.sh as described above.
  3. Adjusting premake4.lua, extern_libs4.lua, update-workspaces.sh and whatever else might be needed to support these changes
  4. Update all affected documentation

Affected documentation:

3. Prepare the libraries for each platform

Assigned: historic_bruno? #1112

Either include precompiled libraries or integrate the source-code into our build-scripts (called from update-workspaces.sh). It depends on the platform and probably on the library if the source or a precompiled version should be included.

4. Write a script to create the bundle from the prebuilt libraries, the game-executables and the data

Assigned: Yves has started creating such a script

  • The script must support the new repository structure
  • It should minimize maintenance effort

5. Check CMake as an alternative in the future or work on improved XCode support for Premake

Assigned: Juicyfruit works on an integration of CMake: #1104

6. Create a plain binary instead of a broken app-bundle

Assigned: Yves #947 Fixed: Changeset 10946

The build-process should create a plain binary in 0a/binaries/system instead of a broken app bundle. A valid app bundle will be created later during deployment.


Attachments (2)

Download all attachments as: .zip

Note: See TracWiki for help on using the wiki.