User:Dydzio/cmake hell

From VCMI Project Wiki
< User:Dydzio
Revision as of 09:24, 14 July 2019 by Dydzio (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

General stuff:

build directory in cmake jargon = MSVS "output directory"

setting ENABLE_TEST true may cause stuff to not compile

for adding new libraries you may have to add "library find module" file to vcmicode/cmake_modules, cmake provides some built-in find modules so that's why there is no find file for boost for example

and do not forget that find files are universal and do not have to be customized for every project, so it makes sense to fight well writen one on internet and copypaste

if library cannot be found make sure your variants of library file name and "last parent directories" are included in the find file

Appveyor etc. related stuff, relevant as of 22.06.2019:

atm vcpkg-related stuff are in osx/cmakelists.txt - pretty counterintuitive, huh?

there is install directory - it is NOT build directory, install(...) command adds stuff to it, then it is used as cache for cpack command to generate appveyor installer

adding qt dlls to INSTALL directory is broken for home building, but works for appveyor, see osx/cmakelists.txt for the code

adding stuff to BUILD directory is done by vcpkg toolchain script, it is required to setup MSVS cmake project properly

adding stuff to INSTALL directory is done by osx/cmakelists.txt and maybe something else

vcpkg toolchain script in version delivered in github repo lacks some features - for example it will NOT copy dependencies for parts of VCMI that produce library and not executable (lua scripting module and luajit for example) - lua51.dll will not get copied

with newer version of toolchain script it will be copied though not in location where we want (scripting subfolder instead of main folder, and I do not see way to control the deps copy procedure)

also with newer version of vcpkg toolchain script copying some other libs will be broken, if you do some builds and then swap script to new one you will hide the errors - in such case wipe out built VCMI files and rebuild project from scratch to see the problem

Travis / MXE etc. related stuff, relevant as of 14.07.2019, including changes in handlersAbstraction branch (PR 456, not merged yet as of that day but should be soon):

Currently Travis uses ubuntu 14, upgrade should be done at some point. So all apt-get stuff in travis scripts will download stuff available for ubuntu 14 (unless adding some custom repo to list).

You need ubuntu, for example in virtual machine to reliably update dependencies package if current one will not suffice. May be beneficial to use same version as travis uses for reproducing more complex build system bugs if doing something more than just update dependencies package.

Travis uses package from releases available here: https://github.com/vcmi/vcmi-deps-mxe - to update package upload new release and update wget and tar commands at the beginning of https://github.com/vcmi/vcmi/blob/develop/CI/mxe/before_install.sh script

Dependencies are based on using prebuilt binaries from MXE package repository, no manual library crosscompiling via MXE is used etc.

Getting these binaries is done via https://github.com/vcmi/vcmi-deps-mxe/blob/master/mirror-mxe.sh - you can run it on ubuntu in VM to get .tar archive with bunch of .deb files, if the script doesn't work then MXE maintainers changed paths (command such as 'echo "deb http://pkg.mxe.cc/repos/apt trusty main" ' fails) and/or signing key is not valid anymore ('sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 86B72ED9' or equivalent command, depends on how the script will change since I write this)

On ubuntu 18 virtual machine I noticed that resulting .tar archive has wrong folder structure compared to current one in release packages. You can manually fix this by unpacking, going into directory with .deb files directly in it and running 'tar cvf filename.tar *' command