Developer's Corner

Here you will find information that helps understanding the Oolite source code, build and test the project.

• Contributing to the project
• Release Process
• Branding, Branding History
• Oolite API documentation
• Doxygen Documentation
• Code Coverage Report
• Cross Platform IDEs
• Compiling with Clang instead of gcc (Windows/Linux)

The build system (architecture)

Here is the result of this forum thread: gitversion.sh / meson.build changes

1. pre-build
   • Iniialise a clean minimal build enviornmnet

     Many issues during or after build are due to having uncessary things being present. Whether this is done through a clean chroot, docker container, VPS, github/gitlab workflow, Virtual machine etc is an implementation detail.

   • download sourcecode

     This should include oolite sourcecode as well as the code needed for external dependencies.

   • install required dependencies

     The baseline discussed at viewtopic.php?p=304440 should make this part a lot easier./p>

     It includes building external deps that are not available in the build environment. Targets that use 'modern builds' for example require gnustep objc2.

     objc2 can only be built by clang, requires gnustep base and make to be built with clang. Also no released versions of gnustep tools support latest clang release (fixes are avaiiable). Targets that use the gcc provided libobjc don't have this need.

   • changes to sourcecode to allow succesfull builds

     example : 1.92-maintenance has 2 files that screw up things at runtime for some targets. Deleting those files is the only option. Although since we updated the dependencies this example should be outdated.

   • set/update values that can not be determined before build time.

     This includes things like sourcecode url, build environment, git commit hash.

     These values shall be passed in a JSON file inside the build directory. An example build file can look like this:

   {
       "title": "Oolite core",
       "identifier": "org.oolite.oolite",
       "required_oolite_version": "1.93",
       "license": "GPL 2+ / CC-BY-NC-SA 3.0 - see LICENSE.md for details",
       "author": "Giles Williams, Jens Ayton and contributors",
       "information_url": "https://oolite.space/",
       "expansion_catalog": "https://addons.oolite.space/api/1.0/overview/"
   }

1. build
   • setup/configure
   • compile
   • test unpackaged
   • install <-- why is this here?
2. post-build
3. packaging
4. testing package

OS Specific parts

Operating System dependent stuff

Procedure	Apple Mac	Linux	Windows
Setting up a development environment	Development on Apple Mac, Cross Platform IDEs	Development on Linux, Cross Platform IDEs	Development on Windows, Cross Platform IDEs
Compiling	Compiling on Apple Mac	Compiling on Linux	Compiling on Windows
Testing	Testing on Apple Mac, Common Testing	Testing on Linux, Common Testing	Testing on Windows, Common Testing
Packaging into Installer	Installer on Apple Mac	Installer on Linux	Installer on Windows
Running	Running Oolite-Mac

Releasing the code

Once you developed a while you might no longer be happy that all you have created is called 'nightly' or 'prerelease' or 'unstable'.

If you are convinced the current status should be published as 'stable' or 'release', follow the Oolite Release Process.

Hints

The code is organized across several git repositories. The main one refers to the others as submodules - but always to a concise commit.

If you need to update submodules you also need to tell people to update the reference in the main repository. Here you can see that handling submodules can lead to strange effects: https://bb.oolite.space/viewtopic.php?f=3&t=21470

To learn mode about submodules read the fine manual at https://git-scm.com/book/en/v2/Git-Tools-Submodules