As discussed in http://forum.openclonk.org/topic_show.pl?tid=2917, I
have merged all copyright notices into a single file and referenced that
merged file from each source file.
For the updated source files, the timeline has been split into three
parts:
1. Pre-RWD code (before 2001)
2. RWD code (2001 through 2009)
3. OpenClonk code (2009 and later)
All pre-RWD copyright notices have been left intact, as have RWD-era
copyright notices where the file did not have a RedWolf design copyright
notice but only individual author ones. All copyright notices of the
OpenClonk era have been replaced by a single notice ranging from the
first recorded year to the current year (2013). Mape code did not get a
OpenClonk Team copyright notice because it is somewhat separate from the
main OpenClonk codebase and has only been touched by Armin Burgmeier.
The planet folder is used to develop the game data and should come first.
The pure exepath is only used on windows, where it is the system data path
and should come last.
With this change, MSVC will build binaries in ${CMAKE_CURRENT_BINARY_DIR}
without adding any more subdirectories. It will also expect its data in a
directory called "planet" immediately below the binary directory.
Since MSVC allows building multiple configurations from the same input file,
the resulting binaries will be suffixed by the configuration type. An exception
is RelWithDebInfo, which will have no suffix; this was chosen over plain Release
to aid in debugging.
Building OpenClonk will work out of the box for in-source builds, but
out-of-source builds will have to create a symlink or a directory junction.
We consider this an acceptable drawback; it was proposed that if you use the
non-default option of an out-of-tree build, you will also know how to create a
link or a junction to, or copy the planet directory.
This changeset also revives looking for game data in the same directory as the
binary, which was part of c3fc1ee1ec8c [Peter Wortmann].
This time, the relocation code checks for a "System.c4g" in either
the executable path or a "data" folder directly below. CMake makes
sure that this points somewhere sensible for normal builds.
TODO:
* Check whether this actually works under Unixes. Can "ln -sf"
delete important stuff? Is there a safe alternative?
* Further unify with the Mac Os solution. Other platforms might
auto-pack for release builds too, for example - and it might
be a good idea to have a proper data subdirectory in Mac bundles
as well.
This replaces the BUILD_TO_PLANET option and makes in-tree Makefile builds
run without further work. Out-of-tree builds need a symlink to planet from
the build directory.
This makes it possible to ship the bundle stand-alone. Also
note that CMake will automatically pack the game data for
release builds, but sym-link the game data for debug builds.
Note this means you will only see the parts of planet/ that
are mentioned in OC_C4GROUPS in CMakeList.txt! This is equivalent
to the behaviour of the shipped build, so I don't see this as
a problem.
Nicolas Hake