Due to an upstream change in vcpkg that breaks the simple integration previously available with `vcpkg integrate install`, building using that setup method is no longer possible. In order to work correctly, cmake must instead be used to generate the VS project files, since that is able to integrate with vcpkg, since vcpkg also uses cmake to build all the library dependencies.
An additional benefit of this is that it will no longer be necessary to separately update the VS project files since it will read the same source_lists files as cmake (on linux) and scons do.
This also enables running the WML unit tests on Windows with this in order to confirm that a valid wesnoth.exe is in fact being generated as well as fixes building the boost unit tests.
The warning level for both release and debug builds are now at level three, the remaining warnings have been fixed, and therefore strict builds have been enabled - any warning will now cause the build to fail, just like for the linux jobs.
Known issues:
* The boost unit tests don't actually run successfully - they fail on CI at least with an exit code on 201 - however I don't know if this is a real problem or just a problem with running headless on CI.
* The debug build doesn't quite work since the executables are built against the non-debug dlls but cmake copies over the debug dlls into the output directory. For now this can be worked around by copying the release dlls into the debug directory.
* The instructions in INSTALL.md are not very good since I don't use Windows and thus can't write anything more detailed. Ideally someone who uses Windows can add more detailed step by step instructions at some point.
Fixes#5741
This has been added as a submodule for convenience of use, since mariadbpp isn't included in any repositories (linux distros, vcpkg, etc) aside from an Arch AUR.
Reasons:
* These projectfiles are still 32-bit, whereas all other builds for all other OSes are now 64-bit.
* Relatedly, these projectfiles are dependent on the libraries kept at the aquileia/external repository.
* VS2019 is still listed as supporting Windows 7, so there is a minimal likelihood of developers not being able to use VS2019.
* The VS2019 projectfiles instead use vcpkg to get the required dependencies, which is easier to setup than the aquileia/external prebuilt libraries.
* It's one less thing that needs to be updated whenever source files are added/moved/removed.
* It's two fewer jobs that Travis needs to run, which means Travis builds will finish more quickly.
Add a "BSD Repository" option.
Add data/dist to .gitignore.
Delete data/dist from git.
Error conditions reading data/dist just set the value to Default.
Remove a leftover TODO comment.
Add description comments for the two new database columns.
* Removed bad openssl include and tuned header search paths
* Xcode project now requires libreadline 7.0 .
Added Fix_Xcode_Dependencies script. Just run it and script take care about all dependencies. No longer need to download Mac Compile Stuff.
Xcode now outputs .app which searches for .dylibs and .frameworks inside Frameworks directory in .app bundle.
* Some fixes and improvements
This commit made with help from @singalen
PR #1725 moved the compiled translations from the translations directory to the po directory.
I would have noticed sooner if Git had not been told to ignore virtually all MO files.
This quells warnings from CMake about reserved target names, and reduces confusion about which `test` is intended: the wesnoth executable or the standard shell command.
At branch 'doc-from-discord-boost-discussion-20170926'.
The build documentation and scripts were slightly out of date about
Boost. This commit makes a (probably interim) update to them.
(CMakeLists.txt|SConstruct): `wesnoth` won't build using Boost earlier
than '1.50.0'. Boost 1.50.0 changed the location of version 3 of Boost
filesystem, from 'boost/filesystem/v3/' (e.g. for
'using boost::filesystem::v3::path;') to 'boost/filesystem/' (e.g. for
'using boost::filesystem::path;', enforced since the very introduction
of 'src/filesystem_boost.cpp'), making it incompatible unless using
precompiler directives for supporting backwards versions of Boost
filesystem prior than '1.50.0'. Using Boost 1.50.0 (and 51, 52 etc.)
`wesnoth` is able build and run. I checked using `ldd` that I am right
about the run time environment.
INSTALL.md: Requirement of Boost libraries version up to date.
projectfiles/VC12/README.md: Requirement of Boost libraries up to
date, only the statement of which one is the minimum version, not the
rest of the build guide for Boost as requirement.
.gitignore: Add KDevelop backup documents.
Changes relative to add-on server:
- Add numbers to map filenames
- Convert 'add-on' to 'campaigns' in file references.
- Set campaign rank
- Remove an unused map
- Remove some images that had been mainlined or had mainline equivalents
- Remove isthiniel portrait since it doesn't match mainline art and is only used briefly
- Updated dwarvish miner and orcish shaman sprites to match SoF and SotBE respectively
- Ran wesnoth optipng on the campaign's images, using:
optipng 0.7.6
advancecomp 1.23
imagemagick 6.9.6.7
- Re-centre bone-bird.png
- Ran wmlindent
While they did contain settings that are required for Wesnoth to run
correctly in the Visual Studio debugger, these settings can also be
specified in the main project file (even if only by manually editing
the XML).
Including the *.user files is problematic since it also includes things
that a developer may wish to frequently change, such as command-line
arguments.
Thus, the settings have been moved into the main project file.
*.vcproj.*.user files contain user specific settings.
*.vcproj.user files contain general settings, e.g. for the debugger, which
are required for our unit tests.
It's convenient for me to do this, because I use scripts to keep
all the configuration info set up correctly, and I have a few diff
versions of mingw and of boost floating around...
