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

Thomas Huth huth at users.berlios.de
Tue Mar 23 00:10:03 CET 2010


On Fri, 19 Mar 2010 23:12:10 +0200
Eero Tamminen <eerot at users.berlios.de> wrote:
> 
> Ok, I get these defines with normal Makefiles:
> -DCONFDIR=\"/usr/local/etc\" -D_GNU_SOURCE=1 -D_REENTRANT
> -DHAVE_LIBPNG=1\ -DHAVE_X11=1   -DENABLE_DSP_EMU=1
> 
> And these with CMake:
> -DCONFDIR=\"/etc\" -DNDEBUG -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> 
> Notes & Questions:
> - HAVE_* stuff is with CMake in config.h which is fine, but
> - Why CONFDIR is /etc?

This is the same what has been done with the autoconf build system in
the past. The system-wide configuration directory is always /etc.
(or would you expect to look into /usr/etc for configuration files of
programs that have been install in /usr instead of /usr/local/ ?)
The rest of the hatari package is relocatable, i.e. you could compile it
with prefix=/usr/local and then still later move the whole package tree
to e.g. /usr or /opt/hatari instead. Hatari will still work.

> - CMake doesn't define "_LARGEFILE64_SOURCE", only "_LARGEFILE_SOURCE"
>   -> which is the thing that bugs zlib.h

1) That's not the problem of CMake, but of "getconf LFS_CFLAGS"
2) Why isn't _FILE_OFFSET_BITS=64 not enough for your zlib.h? That
   works fine on my system there...

> > > $ cmake --version
> > > cmake version 2.6-patch 0
> >
> > I'm using 2.8
> 
> As to using a CMake debug build to get asserts, that doesn't optimize
> code and therefore doesn't get build time warnings so it's about
> useless.

Well, -O3 often breaks debug builds, because on some systems you then
can't use the debugger anymore.

> Then there's RELWITHDEBINFO which uses -g && -O2, but that doesn't
> enable asserts either.

Hm, I think we could also easily tweak this setup, so that asserts get
enabled there. Or we simply introduce our own build style, that has -O3
and asserts enabled... does that sound ok for you?

 Thomas



More information about the hatari-devel mailing list