461 lines
		
	
	
		
			18 KiB
		
	
	
	
		
			ReStructuredText
		
	
			
		
		
	
	
			461 lines
		
	
	
		
			18 KiB
		
	
	
	
		
			ReStructuredText
		
	
| .. highlight:: shell
 | |
| 
 | |
| .. _compile:
 | |
| 
 | |
| ###########
 | |
| Compilation
 | |
| ###########
 | |
| 
 | |
| DFHack builds are available for all supported platforms; see `installing` for
 | |
| installation instructions. If you are a DFHack end-user, modder, or plan on
 | |
| writing scripts [lua] (not plugins), it is generally recommended (and easier) to use
 | |
| these `builds <https://github.com/DFHack/dfhack/releases>`_ instead of compiling DFHack from source.
 | |
| 
 | |
| However, if you are looking to develop plugins, work on the DFHack core, make
 | |
| complex changes to DF-structures, or anything else that requires compiling
 | |
| DFHack from source, this document will walk you through the build process. Note
 | |
| that some steps may be unconventional compared to other projects, so be sure to
 | |
| pay close attention if this is your first time compiling DFHack.
 | |
| 
 | |
| .. contents:: Contents
 | |
|   :local:
 | |
|   :depth: 2
 | |
| 
 | |
| .. _compile-how-to-get-the-code:
 | |
| 
 | |
| How to get the code
 | |
| ===================
 | |
| DFHack uses Git for source control; instructions for installing Git can be found
 | |
| in the platform-specific sections below. The code is hosted on
 | |
| `GitHub <https://github.com/DFHack/dfhack>`_, and can be downloaded with::
 | |
| 
 | |
|     git clone --recursive https://github.com/DFHack/dfhack
 | |
|     cd dfhack
 | |
| 
 | |
| If your version of Git does not support the ``--recursive`` flag, you will need
 | |
| to omit it and run ``git submodule update --init`` after entering the dfhack
 | |
| directory.
 | |
| 
 | |
| This will check out the code on the default branch of the GitHub repo, currently
 | |
| ``develop``, which may be unstable. If you want code for the latest stable
 | |
| release, you can check out the ``master`` branch instead::
 | |
| 
 | |
|     git checkout master
 | |
|     git submodule update
 | |
| 
 | |
| In general, a single DFHack clone is suitable for development - most Git
 | |
| operations such as switching branches can be done on an existing clone. If you
 | |
| find yourself cloning DFHack frequently as part of your development process, or
 | |
| getting stuck on anything else Git-related, feel free to reach out to us for
 | |
| assistance.
 | |
| 
 | |
| .. admonition:: Offline builds
 | |
| 
 | |
|   If you plan to build DFHack on a machine without an internet connection (or
 | |
|   with an unreliable connection), see `note-offline-builds` for additional
 | |
|   instructions.
 | |
| 
 | |
| .. admonition:: Working with submodules
 | |
| 
 | |
|   DFHack uses submodules extensively to manage its subprojects (including the
 | |
|   ``scripts`` folder and DF-structures in ``library/xml``). Failing to keep
 | |
|   submodules in sync when switching between branches can result in build errors
 | |
|   or scripts that don't work. In general, you should always update submodules
 | |
|   whenever you switch between branches in the main DFHack repo with
 | |
|   ``git submodule update``. (If you are working on bleeding-edge DFHack and
 | |
|   have checked out the master branch of some submodules, running ``git pull``
 | |
|   in those submodules is also an option.)
 | |
| 
 | |
|   Rarely, we add or remove submodules. If there are any changes to the existence
 | |
|   of submodules when you switch between branches, you should run
 | |
|   ``git submodule update --init`` instead (adding ``--init`` to the above
 | |
|   command).
 | |
| 
 | |
|   Some common errors that can arise when failing to update submodules include:
 | |
| 
 | |
|   * ``fatal: <some path> does not exist`` when performing Git operations
 | |
|   * Build errors, particularly referring to structures in the ``df::`` namespace
 | |
|     or the ``library/include/df`` folder
 | |
|   * ``Not a known DF version`` when starting DF
 | |
|   * ``Run 'git submodule update --init'`` when running CMake
 | |
| 
 | |
|   Submodules are a particularly confusing feature of Git. The
 | |
|   `Git Book <https://git-scm.com/book/en/v2/Git-Tools-Submodules>`_ has a
 | |
|   thorough explanation of them (as well as of many other aspects of Git) and
 | |
|   is a recommended resource if you run into any issues. Other DFHack developers
 | |
|   are also able to help with any submodule-related (or Git-related) issues
 | |
|   you may encounter.
 | |
| 
 | |
| All Platforms
 | |
| =============
 | |
| Before you can compile the code you'll need to configure your build with cmake. Some IDEs can do this,
 | |
| but from command line is the usual way to do this; thought the Windows section below points out some
 | |
| Windows batch files that can be used to avoid opening a terminal/command-prompt.
 | |
| 
 | |
| You should seek cmake's documentation online or via ``cmake --help`` to see how the command works. See
 | |
| the `build-options` page for help finding the DFHack build options relevant to you.
 | |
| 
 | |
| Before compiling code, you'll of course need code to compile. This **will include** the submodules, so
 | |
| be sure you've read the section about getting the code.
 | |
| 
 | |
| .. _compile-linux:
 | |
| 
 | |
| Linux
 | |
| =====
 | |
| On Linux, DFHack acts as a library that shadows parts of the SDL API using LD_PRELOAD.
 | |
| 
 | |
| Build
 | |
| -----
 | |
| Building is fairly straightforward. Enter the ``build`` folder (or create an
 | |
| empty folder in the DFHack directory to use instead) and start the build like this::
 | |
| 
 | |
|     cd build
 | |
|     cmake .. -G Ninja -DCMAKE_BUILD_TYPE:string=Release -DCMAKE_INSTALL_PREFIX=<path to DF>
 | |
|     ninja install  # or ninja -jX install to specify the number of cores (X) to use
 | |
| 
 | |
| <path to DF> should be a path to a copy of Dwarf Fortress, of the appropriate
 | |
| version for the DFHack you are building. This will build the library along
 | |
| with the normal set of plugins and install them into your DF folder.
 | |
| 
 | |
| Alternatively, you can use ccmake instead of cmake::
 | |
| 
 | |
|     cd build
 | |
|     ccmake .. -G Ninja
 | |
|     ninja install
 | |
| 
 | |
| This will show a curses-based interface that lets you set all of the
 | |
| extra options. You can also use a cmake-friendly IDE like KDevelop 4
 | |
| or the cmake-gui program.
 | |
| 
 | |
| .. _compile-windows:
 | |
| 
 | |
| Windows
 | |
| =======
 | |
| There are several different batch files in the ``win32`` and ``win64``
 | |
| subfolders in the ``build`` folder, along with a script that's used for picking
 | |
| the DF path. Use the subfolder corresponding to the architecture that you want
 | |
| to build for.
 | |
| 
 | |
| First, run ``set_df_path.vbs`` and point the dialog that pops up at
 | |
| a suitable DF installation which is of the appropriate version for the DFHack
 | |
| you are compiling. The result is the creation of the file ``DF_PATH.txt`` in
 | |
| the build directory. It contains the full path to the destination directory.
 | |
| You could therefore also create this file manually - or copy in a pre-prepared
 | |
| version - if you prefer.
 | |
| 
 | |
| Next, run one of the scripts with ``generate`` prefix. These create the MSVC
 | |
| solution file(s):
 | |
| 
 | |
| * ``all`` will create a solution with everything enabled (and the kitchen sink).
 | |
| * ``gui`` will pop up the CMake GUI and let you choose what to build.
 | |
|   This is probably what you want most of the time. Set the options you are interested
 | |
|   in, then hit configure, then generate. More options can appear after the configure step.
 | |
| * ``minimal`` will create a minimal solution with just the bare necessities -
 | |
|   the main library and standard plugins.
 | |
| * ``release`` will create a solution with everything that should be included in
 | |
|   release builds of DFHack. Note that this includes documentation, which requires
 | |
|   Python.
 | |
| 
 | |
| Then you can either open the solution with MSVC or use one of the msbuild scripts.
 | |
| 
 | |
| Visual Studio IDE
 | |
| -----------------
 | |
| After running the CMake generate script you will have a new folder called VC2022
 | |
| or VC2022_32, depending on the architecture you specified. Open the file
 | |
| ``dfhack.sln`` inside that folder. If you have multiple versions of Visual
 | |
| Studio installed, make sure you open with Visual Studio 2022.
 | |
| 
 | |
| The first thing you must then do is change the build type. It defaults to Debug,
 | |
| but this cannot be used on Windows. Debug is not binary-compatible with DF.
 | |
| If you try to use a debug build with DF, you'll only get crashes and for this
 | |
| reason the Windows "debug" scripts actually do RelWithDebInfo builds.
 | |
| After loading the Solution, change the Build Type to either ``Release``
 | |
| or ``RelWithDebInfo``.
 | |
| 
 | |
| Then build the ``INSTALL`` target listed under ``CMakePredefinedTargets``.
 | |
| 
 | |
| Command Line
 | |
| ------------
 | |
| In the build directory you will find several ``.bat`` files:
 | |
| 
 | |
| * Scripts with ``build`` prefix will only build DFHack.
 | |
| * Scripts with ``install`` prefix will build DFHack and install it to the previously selected DF path.
 | |
| * Scripts with ``package`` prefix will build and create a .zip package of DFHack.
 | |
| 
 | |
| Compiling from the command line is generally the quickest and easiest option.
 | |
| Modern Windows terminal emulators such as `Cmder <https://cmder.app/>`_ or
 | |
| `Windows Terminal <https://github.com/microsoft/terminal>`_ provide a better
 | |
| experience by providing more scrollback and larger window sizes.
 | |
| 
 | |
| .. _compile-macos:
 | |
| 
 | |
| macOS
 | |
| =====
 | |
| DFHack functions similarly on macOS and Linux, and the majority of the
 | |
| information above regarding the build process (CMake and Ninja) applies here
 | |
| as well.
 | |
| 
 | |
| DFHack can officially be built on macOS only with GCC 4.8 or 7. Anything newer than 7
 | |
| will require you to perform extra steps to get DFHack to run (see `osx-new-gcc-notes`),
 | |
| and your build will likely not be redistributable.
 | |
| 
 | |
| Building
 | |
| --------
 | |
| 
 | |
| * Get the DFHack source as per section `compile-how-to-get-the-code`, above.
 | |
| * Set environment variables
 | |
| 
 | |
|   Homebrew (if installed elsewhere, replace /usr/local with ``$(brew --prefix)``)::
 | |
| 
 | |
|     export CC=/usr/local/bin/gcc-7
 | |
|     export CXX=/usr/local/bin/g++-7
 | |
| 
 | |
|   Macports::
 | |
| 
 | |
|     export CC=/opt/local/bin/gcc-mp-7
 | |
|     export CXX=/opt/local/bin/g++-mp-7
 | |
| 
 | |
|   Change the version numbers appropriately if you installed a different version of GCC.
 | |
| 
 | |
|   If you are confident that you have GCC in your path, you can omit the absolute paths::
 | |
| 
 | |
|     export CC=gcc-7
 | |
|     export CXX=g++-7
 | |
| 
 | |
|   (adjust as needed for different GCC installations)
 | |
| 
 | |
| * Build DFHack::
 | |
| 
 | |
|     mkdir build-osx
 | |
|     cd build-osx
 | |
|     cmake .. -G Ninja -DCMAKE_BUILD_TYPE:string=Release -DCMAKE_INSTALL_PREFIX=<path to DF>
 | |
|     ninja install  # or ninja -jX install to specify the number of cores (X) to use
 | |
| 
 | |
|   <path to DF> should be a path to a copy of Dwarf Fortress, of the appropriate
 | |
|   version for the DFHack you are building.
 | |
| 
 | |
| .. _osx-new-gcc-notes:
 | |
| 
 | |
| Notes for GCC 8+ or OS X 10.10+ users
 | |
| -------------------------------------
 | |
| 
 | |
| If you have issues building on OS X 10.10 (Yosemite) or above, try defining
 | |
| the following environment variable::
 | |
| 
 | |
|     export MACOSX_DEPLOYMENT_TARGET=10.9
 | |
| 
 | |
| If you build with a GCC version newer than 7, DFHack will probably crash
 | |
| immediately on startup, or soon after. To fix this, you will need to replace
 | |
| ``hack/libstdc++.6.dylib`` with a symlink to the ``libstdc++.6.dylib`` included
 | |
| in your version of GCC::
 | |
| 
 | |
|   cd <path to df>/hack && mv libstdc++.6.dylib libstdc++.6.dylib.orig &&
 | |
|   ln -s [PATH_TO_LIBSTDC++] .
 | |
| 
 | |
| For example, with GCC 6.3.0, ``PATH_TO_LIBSTDC++`` would be::
 | |
| 
 | |
|   /usr/local/Cellar/gcc@6/6.3.0/lib/gcc/6/libstdc++.6.dylib  # for 64-bit DFHack
 | |
|   /usr/local/Cellar/gcc@6/6.3.0/lib/gcc/6/i386/libstdc++.6.dylib  # for 32-bit DFHack
 | |
| 
 | |
| **Note:** If you build with a version of GCC that requires this, your DFHack
 | |
| build will *not* be redistributable. (Even if you copy the ``libstdc++.6.dylib``
 | |
| from your GCC version and distribute that too, it will fail on older OS X
 | |
| versions.) For this reason, if you plan on distributing DFHack, it is highly
 | |
| recommended to use GCC 4.8 or 7.
 | |
| 
 | |
| .. _osx-m1-notes:
 | |
| 
 | |
| Notes for M1 users
 | |
| ------------------
 | |
| 
 | |
| Alongside the above, you will need to follow these additional steps to get it
 | |
| running on Apple silicon.
 | |
| 
 | |
| Install an x86 copy of ``homebrew`` alongside your existing one. `This
 | |
| stackoverflow answer <https://stackoverflow.com/a/64951025>`__ describes the
 | |
| process.
 | |
| 
 | |
| Follow the normal macOS steps to install ``cmake`` and ``gcc`` via your x86 copy of
 | |
| ``homebrew``. Note that this will install a GCC version newer than 7, so see
 | |
| `osx-new-gcc-notes`.
 | |
| 
 | |
| In your terminal, ensure you have your path set to the correct homebrew in
 | |
| addition to the normal ``CC`` and ``CXX`` flags above::
 | |
| 
 | |
|   export PATH=/usr/local/bin:$PATH
 | |
| 
 | |
| Windows cross compiling from Linux (running DF inside docker)
 | |
| =============================================================
 | |
| 
 | |
| .. highlight:: bash
 | |
| 
 | |
| You can use docker to build DFHack for Windows. These instructions were developed
 | |
| on a Linux host system.
 | |
| 
 | |
| .. contents::
 | |
|   :local:
 | |
|   :depth: 1
 | |
| 
 | |
| Step 1: prepare a docker image
 | |
| ------------------------------
 | |
| 
 | |
| On your Linux host, install and run the docker daemon and then run these commands::
 | |
| 
 | |
|     xhost +local:root
 | |
|     git clone https://github.com/BenLubar/build-env.git
 | |
|     cd build-env/msvc
 | |
|     docker build .
 | |
|     docker image ls
 | |
|     IMAGE_ID=<your image id>
 | |
|     docker run -it --env="DISPLAY" --env="QT_X11_NO_MITSHM=1" --volume=/tmp/.X11-unix:/tmp/.X11-unix --user buildmaster --name dfhack-win $IMAGE_ID
 | |
| 
 | |
| The ``xhost`` command and ``--env`` parameters are there so you can eventually
 | |
| run Dwarf Fortress from the container and have it display on your host.
 | |
| 
 | |
| Step 2: build DFHack
 | |
| --------------------
 | |
| 
 | |
| The ``docker run`` command above will give you a shell prompt (as the ``buildmaster`` user) in the
 | |
| container. Inside the container, run the following commands::
 | |
| 
 | |
|     git clone https://github.com/DFHack/dfhack.git
 | |
|     cd dfhack
 | |
|     git submodule update --init
 | |
|     cd build
 | |
|     dfhack-configure windows 64 Release
 | |
|     dfhack-make
 | |
| 
 | |
| Inside the ``dfhack-*`` scripts there are several commands that set up the wine
 | |
| server. Each invocation of a Windows tool will cause wine to run in the container.
 | |
| Preloading the wineserver and telling it not to exit will speed configuration and
 | |
| compilation up considerably (approx. 10x). You can configure and build DFHack
 | |
| with regular ``cmake`` and ``ninja`` commands, but your build will go much slower.
 | |
| 
 | |
| Step 3: copy Dwarf Fortress to the container
 | |
| --------------------------------------------
 | |
| 
 | |
| First, create a directory in the container to house the Dwarf Fortress binary and
 | |
| assets::
 | |
| 
 | |
|     mkdir ~/df
 | |
| 
 | |
| If you can just download Dwarf Fortress directly into the container, then that's fine.
 | |
| Otherwise, you can do something like this in your host Linux environment to copy an
 | |
| installed version to the container::
 | |
| 
 | |
|     cd ~/.steam/steam/steamapps/common/Dwarf\ Fortress/
 | |
|     docker cp . dfhack-win:df/
 | |
| 
 | |
| Step 4: install DFHack and run DF
 | |
| ---------------------------------
 | |
| 
 | |
| Back in the container, run the following commands::
 | |
| 
 | |
|     cd dfhack/build
 | |
|     cmake .. -DCMAKE_INSTALL_PREFIX=/home/buildmaster/df
 | |
|     ninja install
 | |
|     cd ~/df
 | |
|     wine64 "Dwarf Fortress.exe"
 | |
| 
 | |
| Other notes
 | |
| -----------
 | |
| 
 | |
| Closing your shell will kick you out of the container. Run this command on your Linux
 | |
| host when you want to reattach::
 | |
| 
 | |
|     docker start -ai dfhack-win
 | |
| 
 | |
| If you edit code and need to rebuild, run ``dfhack-make`` and then ``ninja install``.
 | |
| That will handle all the wineserver management for you.
 | |
| 
 | |
| Cross-compiling windows files for running DF in Steam for Linux
 | |
| ===============================================================
 | |
| 
 | |
| .. highlight:: bash
 | |
| 
 | |
| If you wish, you can use Docker to build just the Windows files to copy to your
 | |
| existing Steam installation on Linux.
 | |
| 
 | |
| .. contents::
 | |
|   :local:
 | |
|   :depth: 1
 | |
| 
 | |
| Step 1: Build the MSVC builder image
 | |
| ------------------------------------
 | |
| 
 | |
| It'll be called ``dfhack-build-msvc:latest`` after it's done building::
 | |
| 
 | |
|    git clone https://github.com/BenLubar/build-env.git
 | |
|    cd build-env/msvc
 | |
|    docker build -t dfhack-build-msvc .
 | |
| 
 | |
| The docker build takes a while, but only needs to be done once, unless the build
 | |
| environment changes.
 | |
| 
 | |
| Step 2: Get dfhack, and run the build script
 | |
| --------------------------------------------
 | |
| 
 | |
| Check out ``dfhack`` into another directory, and run the build script::
 | |
| 
 | |
|    git clone https://github.com/DFHack/dfhack.git
 | |
|    cd dfhack
 | |
|    git submodule update --init --recursive
 | |
|    cd build
 | |
|    ./build-win64-from-linux.sh
 | |
| 
 | |
| The script will mount your host's ``dfhack`` directory to docker, use it to
 | |
| build the artifacts in ``build/win64-cross``, and put all the files needed to
 | |
| install in ``build/win64-cross/output``.
 | |
| 
 | |
| If you need to run ``docker`` using ``sudo``, run the script using ``sudo``
 | |
| rather than directly::
 | |
| 
 | |
|   sudo ./build-win64-from-linux.sh
 | |
| 
 | |
| Step 3: install dfhack to your Steam DF install
 | |
| -----------------------------------------------
 | |
| As the script will tell you, you can then copy the files into your DF folder::
 | |
| 
 | |
|    # Optional -- remove the old hack directory in case we leave files behind
 | |
|    rm ~/.local/share/Steam/steamapps/common/"Dwarf Fortress"/hack
 | |
|    cp -r win64-cross/output/* ~/.local/share/Steam/steamapps/common/"Dwarf Fortress"/
 | |
| 
 | |
| Afterward, just run DF as normal.
 | |
| 
 | |
| .. _note-offline-builds:
 | |
| 
 | |
| Building DFHack Offline
 | |
| =======================
 | |
| As of 0.43.05, DFHack downloads several files during the build process, depending
 | |
| on your target OS and architecture. If your build machine's internet connection
 | |
| is unreliable, or nonexistent, you can download these files in advance.
 | |
| 
 | |
| First, you must locate the files you will need. These can be found in the
 | |
| `dfhack-bin repo <https://github.com/DFHack/dfhack-bin/releases>`_. Look for the
 | |
| most recent version number *before or equal to* the DF version which you are
 | |
| building for. For example, suppose "0.43.05" and "0.43.07" are listed. You should
 | |
| choose "0.43.05" if you are building for 0.43.05 or 0.43.06, and "0.43.07" if
 | |
| you are building for 0.43.07 or 0.43.08.
 | |
| 
 | |
| Then, download all of the files you need, and save them to ``<path to DFHack
 | |
| clone>/CMake/downloads/<any filename>``. The destination filename you choose
 | |
| does not matter, as long as the files end up in the ``CMake/downloads`` folder.
 | |
| You need to download all of the files for the architecture(s) you are building
 | |
| for. For example, if you are building for 32-bit Linux and 64-bit Windows,
 | |
| download all files starting with ``linux32`` and ``win64``. GitHub should sort
 | |
| files alphabetically, so all the files you need should be next to each other.
 | |
| 
 | |
| .. note::
 | |
| 
 | |
|   * Any files containing "allegro" in their filename are only necessary for
 | |
|     building `stonesense`. If you are not building Stonesense, you don't have to
 | |
|     download these, as they are larger than any other listed files.
 | |
| 
 | |
| It is recommended that you create a build folder and run CMake to verify that
 | |
| you have downloaded everything at this point, assuming your download machine has
 | |
| CMake installed. This involves running a "generate" batch script on Windows, or
 | |
| a command starting with ``cmake .. -G Ninja`` on Linux and macOS, following the
 | |
| instructions in the sections above. CMake should automatically locate files that
 | |
| you placed in ``CMake/downloads``, and use them instead of attempting to
 | |
| download them.
 |