Project

General

Profile

Bug #858

CmakeLists.txt issues (minor)

Added by arclore over 14 years ago. Updated over 11 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
2010-01-21
% Done:

100%


Description

deng_VERSION_REVISION is still set to "beta5"
-The envpaths ZLIBDIR, LIBPNGDIR, and LIBCURLDIR should probablly point to the "/external" directory in the source, i.e.
SET
If cmake expects things to be in "c:/sdk/" then the documentation should indicate that.
- 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

History

#1 Updated by danij over 14 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 14 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.

#3 Updated by skyjake over 14 years ago

Use of CMake will be phased out eventually. Some of these issues have been resolved in the master branch.

#4 Updated by arclore almost 14 years ago

- NAMES for find_library in DirectSound and DirectInput do not seem to be up-to-date. It appears that it should be "dsound" instead of "libdsound", and "dinput" instead of "libdinput".

Also available in: Atom PDF