DFHACK_BUILD_ARCH is no longer cached on Windows since it is not possible
to build Win32 targets with the Win64 generator or vice versa. No change
for GCC builds.
As best as I can tell, the copy of tinyxml dfhack uses is unmodified
from whenever it was first bundled. This commit adds an option to CMake,
EXTERNAL_TINYXML, that if set to ON, will attempt to link against a system
tinyxml instead of using the dfhack-bundled one. It defaults to OFF,
so there is no change in default behavior.
The DFHACK_TINYXML variable is then set to either "tinyxml" or "dfhack-tinyxml"
so the library (and any plugins that need updating) can link against one
or the other.
The FindTinyXML.cmake script was taken from https://github.com/ros/cmake_modules
(licensed under the 3-clause BSD license).
Add license text to new CMake file.
This relies on a working cross-compiler, of course, as well as a separate build
directory for cross-compiled builds, with DFHACK_NATIVE_BUILD_DIR pointing
to an already-successful native build directory (this is needed for protoc).
GCC 5 mangles some symbols, such as "plugin_globals" ->
"plugin_globals[abi:c++11]" (or "_Z14plugin_globalsB5cxx11"), even
when declared with 'extern "C"'. This breaks plugins, in particular.
Having the docs index in the repo root was a holdover from when it was
the README file. Now that it's not much use without being built, it's
better to leave the root to README, NEWS, and LICENSE - especially when
one is a html shortcut to the docs index.
The root of the documentation tree has a different function to the short
readme we want to display on GitHub, which now links to the main docs
(or Bay12 thread, or IRC). It also renders properly on GitHub, and can
use live-updating status badges because we don't expect it to work
offline.
Building the docs now works the same way, no matter when it happens - in
a cloned repo or distributed version.
This means all the relative links keep working; and that users or
downstream distributors can rebuild the docs with extra scripts or .rst
files in place.
Finally, it eliminates a large number of potential bugs which only occur
in one build environment and are difficult to reproduce.
Also add headings and this work to future news.
This mainly involved tweaking a few filenames and configuration paths to
allow consistency in all scenarios. It cleared up a few errors in the
process too!
I also clarified the placement of the LICENSE file, and finished
configuring the Alabaster style. This required moving some stuff out of
the CMake system to conf.py to avoid later breakage.
Repos need to include a CMakeLists.txt file with calls to the
DFHACK_SCRIPTS macro, which functions similarly to DFHACK_PLUGIN.
The `open-legends` script from lethosor/dfhack-scripts is included
as an example.
Files from the "dfhack-config" source directory are now installed to
"dfhack-config/default" and copied to "dfhack-config" on startup if
they don't already exist. Previously, config files weren't available
at all unless they were manually installed (93c9a41).
Widget positions and a few other options (e.g. date formats) can be
specified in dfhack-config/dwarfmonitor.json on a per-instance basis.
Related changes:
* Fixed an issue loading JSON files from Lua
* JSON files in dfhack-config (only dwarfmonitor.json currently) are
no longer copied into the DF directory when building DFHack. This
keeps developers' personal settings intact, but will require
copying over changes made to DFHack's copies manually.
* Fixed incorrect config path in dwarfmonitor help
This allows plugins with vmethod hooks to be reloaded on OS X by making paths
embedded in shared libraries use @rpath instead of embedding the build
directory, which avoids the need to change them them later. Modifying paths in
libdfhack.dylib caused it to be reloaded, which prevented hooks from working.
lethosor
Carter Bray
Vitaly Pronkin
Michael Casadevall
Lethosor
Ben Rosser
expwnent
James Gilles
TheBloke
PeridexisErrant
Alexander Gavrilov
expwnent