[hatari-devel] Issues with CMake/CMakeLists.txt
Eero Tamminen
eerot at users.berlios.de
Fri Mar 19 21:32:55 CET 2010
Hi,
On Friday 19 March 2010, Thomas Huth wrote:
> > I think just this should be enough:
> > add_subdirectory(python-ui)
>
> Ok, that sounds reasonable.
>
> > And maybe something like this:
> > include(FindPythonInterp)
> > if(PYTHONINTERP_FOUND)
> > message(STATUS "WARNING: Python not present, hatariui cannot
> > be run in the build environment!")
> > endif(PYTHONINTERP_FOUND)
>
> Well, I think that could also be annoying for people who do not need
> the the python-ui and don't have python installed (e.g. on Windows).
> So let's keep it simple, without warning message.
Hm. Maybe in that case it's better to leave it as it is.
All major Linux distros include Python in their base system
(in Ubuntu it's even declared essential), so Linux packagers
should always get python UI stuff.
> This is certainly caused by the fact that the CMakeLists.txt in the
> topmost directory turns on large filesystem support via "getconf
> LFS_CFLAGS" - which is not done by the old Makefiles.
> But you should not get warning messages because of this - unless your
> zlib.h is broken. My zlib.h looks like this here:
...
Mine looks the same.
> That means it does both, declaring the right prototypes and then
> re-defining the functions to the 64-bit versions.
Btw. How do I enabled showing of compiler options & flags with CMake?
> > For example isblank() manual page says:
> > Feature Test Macro Requirements for glibc (see
> > feature_test_macros(7)): isascii(): _BSD_SOURCE || _SVID_SOURCE ||
> > _XOPEN_SOURCE isblank(): _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE; or
> > cc -std=c99
>
> That's interesting... but I can't see how CMake could cause that
> warning. Could you check the corresponding header file in which case
> it defines isblank() and in which case is does not?
ctype.h:
# ifdef __USE_ISOC99
# define isblank(c) __isctype((c), _ISblank)
# endif
features.h:
--------------
#ifdef _GNU_SOURCE
# define _ISOC99_SOURCE 1
...
# define _LARGEFILE64_SOURCE 1
...
#endif
#if (defined _ISOC99_SOURCE || defined _ISOC9X_SOURCE \
|| (defined __STDC_VERSION__ && __STDC_VERSION__ >= 199901L))
# define __USE_ISOC99 1
#endif
#ifdef _XOPEN_SOURCE
# if (_XOPEN_SOURCE - 0) >= 500
# define _LARGEFILE_SOURCE 1
# if (_XOPEN_SOURCE - 0) >= 600
# define __USE_ISOC99 1
# endif
#endif
#ifdef _LARGEFILE64_SOURCE
# define __USE_LARGEFILE64 1
#endif
---------------
And:
$ sdl-config --cflags
-I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT
So sdl-config brings in _GNU_SOURCE which brings in LFS, C99 etc.
> > When I ran ccmake (cmake ncurses UI) and switched it to advanced mode,
> > I noticed that it at least turns assert()s off by default.
>
> You've got to tell CMake to generate a debug build (set
> CMAKE_BUILD_TYPE to Debug), then it will keep the asserts enabled.
> When you specify nothing, it will create a Release build - which has
> asserts turned off.
>
> > CMake defines SDL_LIBRARY
> > as: /usr/lib/libSDLmain.a;/usr/lib/libSDL.so;-lpt
>
> This is done by the standard FindSDL.cmake package that is shipped with
> CMake. I think they now what they're doing. If not, they would probably
> get a lot of complaints on their mailing lists... ;-)
Well, it seems that CMake doesn't use sdl-config and therefore doesn't
use _GNU_SOURCE, so it craps out my build.
> > Eventually build with CMake fails with:
> > make[2]: *** No rule to make target `../doc/hatari.1.gz', needed by
> > `doc/CMakeFiles/manpages'. Stop.
> > make[1]: *** [doc/CMakeFiles/manpages.dir/all] Error 2
> > make: *** [all] Error 2
>
> Huh? Strange, this works for me, and I can't see any obvious problem in
> doc/CMakeLists.txt ... which version of CMake are you using?
One from Debian stable (Lenny) i.e.
$ cmake --version
cmake version 2.6-patch 0
- Eero
More information about the hatari-devel
mailing list