CmakeLists.txt issues (minor)
deng_VERSION_REVISION is still set to "beta5" If cmake expects things to be in "c:/sdk/" then the documentation should indicate that.
-The envpaths ZLIBDIR, LIBPNGDIR, and LIBCURLDIR should probablly point to the "/external" directory in the source, i.e.
- I might be dumb and/or nitpicky, but isn't it redundant to have an IF (NOT WIN32) inside an IF (UNIX), or vice versa? Or IF (UNIX AND NOT WIN32)?
- There's no cmake module for SDL, SDL_mixer, or SDL_net. As a result cmake has a great deal of difficulty finding them on its own.
- Why is Python required? There's no hint of this in the docs.
- The files specified in the package-not-found MESSAGE (FATAL ERROR ) are somewhat out of date. Possibly needs a "version xxx or later", or better yet, just a URL.
- Several of the module files in /build/cmake need additional paths in order to find their targets. For example, the most recent DirectX SDK has its lib divided into two subdirectories, one for x86, the other for x64.
Labels: Build System
#1 Updated by danij over 12 years ago
Cmake is not fully setup for use on WIN32. On WIN32 you currently have three options:
Use the Visual C++ solution, found in \build\win32\vs8
Use the Visual C++ command line compiler with vcbuild.bat, found in \build\win32
Use the CodeBlocks solution, found in \build\codeblocks and the Visual C++ command line compiler
CmakeLists as since been rewritten by skyjake (and now can be used on WIN32 too) but is not yet usable to produce a release build. As of Doomsday 1.9.0-beta7 we will be switching to cmake on all supported platforms.
#2 Updated by arclore over 12 years ago
Another small note:
While puttering around with cmake i noticed that some of the Find*.cmake files in doomsday/build/cmake look like they're modified versions of the default FIND_PACKAGE modules included with Cmake. This is especially noticeable with FindPNG.
One of the changes has been to delete Cmake's OSI-BSD copyright.
I don't want to be "that guy", but that seems a little... iffy.