cmake file for all about devilution HOT 8 CLOSED

Please create Pull Request

from devilution.

Also, not really a fan of using CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS to set the option globally and prefer to set it on each target as necessary, but it's fine here I guess?

because, i had some troubles with def file and vc++ linker

@OvermindDL1

It's generally very bad form to use something like DEVILUTION_SRC and instead should just list the source files in the add_* calls directly.

why? cmake authors use the same https://gitlab.kitware.com/cmake/cmake/blob/master/Source/CMakeLists.txt#L105

from devilution.

Good start. :-)

A few notes about it:

• Should add the version information, homepage (this git repo?), etc... to the project call. Might also be good to explicitly list LANGUAGES CXX to make it explicit what is in use, though this is optional as the default value is built-in as LANGUAGES CXX C ASM (though could set it to that).
• It's generally very bad form to use something like DEVILUTION_SRC and instead should just list the source files in the add_* calls directly.
• Should also use target_include_directories to add the include directories as well (even if it is just the source directory).
• add_library generally should use a namespaced alias as well, though in this specific reverse engineering case it's not really needed, but it is still good form.
• Traditionally variables should not be used in the target field either (the ${PROJECT_NAME} bits) as explicit names is always preferred over implicit so you know what exactly is being created here instead of needing to go look up at the project definition to find out.
• Oh, and when things like the source files are moved to the add_executable and so forth things (as well as the add_library) each file listed should be on it's own line, indented over (I prefer a tab so I can set the displayed tab width to whatever I want for the display I'm on, but it doesn't really matter, though as always "Tabs for Indentation, Spaces for alignment" and all), as it increases readability.

:-)

from devilution.

Also, not really a fan of using CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS to set the option globally and prefer to set it on each target as necessary, but it's fine here I guess? Though I'm unsure that the executable itself needs it set anyway, or even the libraries depending on how they are programmed?

from devilution.

why?

It's just considered poor form nowadays as it separates concerns that don't need to be separated. Using a variable implies the source files are used in multiple targets instead of just one. They are entirely fine to use if the file lists will be shared however, but if only a single target uses them then they shouldn't. See CGold.

from devilution.

Does this work with the latest commit? If so, what are the advantages of the project being CMake compatible?

from devilution.

Unless anyone wishes to work on integrating CMake into Devilution, I suggest we close this issue as most users would be building DevilutionX which already supports CMake builds. Devilution is only ever used to verify binary accuracy and thus requires the original build environment.

from devilution.

Agreed, the only reason we also build with other compilers is to avoid tainting the code with things that is to specific to Windows 95 workstations.

from devilution.