upstream/wesnoth
1
0
Fork 0
mirror of https://github.com/wesnoth/wesnoth synced 2025-05-02 04:35:45 +00:00
Code Issues Packages Projects Releases Wiki Activity
wesnoth/projectfiles/CodeBlocks
History
Pentarctagon 971073055e
Refactor the preferences into a proper singleton. (#8930) 
The current preferences handling is a mess:
* it's essentially a global config object that anything can modify in any way the caller wants, which is managed across multiple source files which have their own oddities and interdependencies.
* the general preferences has its own bit of SDL event handling and while I get the idea behind `events::sdl_handler` there's no reason to have SDL events handled in the preferences instead of just calling the relevant preferences setter for each event when it happens.
* the general preferences is where most of the preferences are handled and has its `base_manager` struct, which is part of the `manager` struct in the game preferences, which is then implicitly initialized as part of game_launcher's constructor.
* the editor preferences are the only preferences in a sub-namespace `preferences::editor` while all other preferences are just in the `preferences` namespace.
* the display, editor, and lobby preferences are all dependent on including the game preferences, the credentials are dependent on including the general preferences (but not the game preferences), the game preferences are dependent on including the general preferences, and the advanced preferences are entirely their own thing which is dependent on none of the other preference functionality and manages its own singleton.
* nothing checks whether the preferences file has actually been loaded before allowing values to be read from or written to the preferences config - if you attempt to get a value too early in wesnoth's initialization it will silently just give you whatever the default value for that preference happens to be.

With this there is instead a single access point (with exceptions handled via friend functions/classes), all predefined preferences are accessed via their own setter/getter, and all mainline preferences are defined in a single file (preference_list.hpp) so it's easily findable what preferences exist and where they're used. Having the list of all mainline preferences listed out also allows the lua preferences API to provide that full list rather than just the list of the preferences that have been set so far. Also it now checks for whether the location of the preferences file is known before attempting to load the preferences file and asserts if someone attempts to use the preferences too early.
2024-06-09 11:34:09 -05:00
..
campaignd.cbp
Further consolidate logging functionality between Windows and non-Windows platforms.
2023-02-17 10:03:05 -06:00
liblua.cbp
…
libraries.md
update list of boost headers used in compilation
2024-02-27 15:21:11 +01:00
README.md
…
tests.cbp
Refactor the preferences into a proper singleton. (#8930)
2024-06-09 11:34:09 -05:00
wesnoth.cbp
Refactor the preferences into a proper singleton. (#8930)
2024-06-09 11:34:09 -05:00
wesnoth.workspace
…
wesnothd.cbp
Further consolidate logging functionality between Windows and non-Windows platforms.
2023-02-17 10:03:05 -06:00

README.md

Compiling Wesnoth on Windows using CodeBlocks

(Last tested using Wesnoth 1.15.9+ on Code::Blocks 17.12)

  1. Get a Wesnoth source tarball or Git repository clone. The folder which contains the data/, projectfiles/, and src/ subfolders is referred to as wesnoth_root in this file.

  2. Install CodeBlocks from http://www.codeblocks.org/. MinGW is not needed.

  3. Download and unpack MinGW-w64 from https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/8.1.0/threads-posix/seh/x86_64-8.1.0-release-posix-seh-rt_v6-rev0.7z. Note that the project files in wesnoth_root/projectfiles/CodeBlocks/ may contain a setting to compile with OpenMP support, so you should make sure that this option is enabled while installing the compiler (mark the checkbox for this when choosing components to install).

    NOTE: You must make sure to download the 64-bit version.

    If you download the 32 bit version and you have out of memory errors when creating debug builds, you can follow these steps:

    1. If you use 32-bit Windows, run in admin command prompt
    bcdedit/set IncreaseUserVa 3072

    1. Install MASM32;

    2. Open cmd (also as admin);

    3. Run these commands in an admin command prompt

    cd C:\..\mingw32\libexec\gcc\i686-w64-mingw32\7.2.0

C:\masm32\bineditbin.exe /LARGEADDRESSAWARE cc1plus.exe

    If you use the 64-bit version then you cannot use MASM32 since it doesn't have a 64 bit version, which means you cannot make a debug build.

  4. Download the latest CodeBlocksWinSDK*.zip package from http://sourceforge.net/projects/wesnoth/files/SDK/. The package contains the right version/build combination of source headers, build-time libraries (*.a) and run-time libraries (*.dll) needed to build and run Wesnoth. Older versions of the package may no longer be useful after new dependencies are added to Wesnoth or its version requirements change.

    for versions > 1.12, follow the steps in libraries.md to update libraries yourself.

    Unpack the file to any path of your choice, which will be referred to as sdk_root for the remainder of this file.

    The exact names of the folders containing the required files may vary; take note of them for the next steps.

  5. In CodeBlocks, open wesnoth_root/projectfiles/CodeBlocks/wesnoth.workspace.

    NOTE: The first time CodeBlocks is opened you will be asked to select a compiler. If installation from step 3 is complete it may detect it for you, in which case you can select the GNU GCC compiler which will produce some default selections for step 6 - be sure to change any that don't match as directed below.

  6. Go to the Settings -> Compiler option in the menu, and choose the Global compiler settings -> Toolchain executables tab in the settings dialog. Enter the following settings into the text boxes:

    • Compiler's installation directory: the path to which you installed mingw-w64 (click on ... to browse for it).
    • C compiler, C++ compiler, Linker for dynamic libs: g++.exe
    • Linker for static libs: ar.exe

  7. Change to the Search directories -> Compiler tab and choose Add; enter the path to sdk_root/include_w64-mingw32/.

  8. Change to the Search directories -> Linker tab and choose Add; enter the path to sdk_root/lib_w64-mingw32/.

  9. OPTIONAL: By default, CodeBlocks will only run one compiler instance at a time, making the overall build process very slow even with fast hardware. If you have a multi-core processor, you may make better use of its power by increasing the value of the option "Number of processes for parallel builds" in the Build options tab. It is recommended to set this to the number of CPU cores your system has.

  10. Close the settings dialog.

  11. Choose the Build -> Build workspace option in the CodeBlocks menu. Once finished, wesnoth.exe and wesnothd.exe should appear in wesnoth_root.

  12. To be able to run your build, copy all *.dll files from the sdk_root/dll/ folder to wesnoth_root where the *.exe files are.