[hatari-devel] Issues with CMake/CMakeLists.txt

Thomas Huth huth at users.berlios.de
Fri Mar 19 20:58:27 CET 2010


On Tue, 16 Mar 2010 23:08:42 +0200
Eero Tamminen <eerot at users.berlios.de> wrote:

> Python is needed only when running the python scripts.  When creating
> Hatari packages, requiring Python to get e.g. hatariui installed is
> IMHO even wrong thing to do (packages may be built on different
> machine than where they're installed).
> 
> 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.

> /hatari/src/file.c: In function ‘File_Read’:
> /hatari/src/file.c:193: warning: implicit declaration of function
> ‘gzopen64’
> /hatari/src/file.c:193: warning: assignment makes pointer
> from integer without a cast
> /hatari/src/file.c:200: warning: implicit declaration of function
> ‘gzseek64’
> /hatari/src/file.c:203: warning: implicit declaration of
> function ‘gztell64’
> /hatari/src/file.c: In function ‘File_Save’:
> /hatari/src/file.c:268: warning: assignment makes pointer from
> integer without a cast

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:

#if defined(_LARGEFILE64_SOURCE) || _FILE_OFFSET_BITS == 64
   ZEXTERN gzFile ZEXPORT gzopen64 OF((const char *, const char *));
   ZEXTERN z_off64_t ZEXPORT gzseek64 OF((gzFile, z_off64_t, int));
   ZEXTERN z_off64_t ZEXPORT gztell64 OF((gzFile));
   ZEXTERN uLong ZEXPORT adler32_combine64 OF((uLong, uLong, z_off64_t));
   ZEXTERN uLong ZEXPORT crc32_combine64 OF((uLong, uLong, z_off64_t));
#endif

#if _FILE_OFFSET_BITS == 64
#  define gzopen gzopen64
#  define gzseek gzseek64
#  define gztell gztell64
#  define adler32_combine adler32_combine64
#  define crc32_combine crc32_combine64
#else
...
#endif

That means it does both, declaring the right prototypes and then
re-defining the functions to the 64-bit versions.
What is your zlib.h doing?

> 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?


> 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... ;-)

> 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?

> PS. In general CMake seems nice and it seems to have pretty extensive
> documentation in its the Debian package.

Yes, documentation is really good and also looks much better to me than
the docs for the autoconf stuff... that's also one of the many reasons I
was finally pushing for CMake instead of autoconf ;-)

 Thomas



More information about the hatari-devel mailing list