[hatari-devel] CMake build system

Eero Tamminen eerot at users.berlios.de
Tue Jan 19 23:57:04 CET 2010


Hi,

On Sunday 10 January 2010, Thomas Huth wrote:
> As you might have already seen in the repository, I recently started to
> add CMake build files to Hatari. Now I think it's stable enough so that
> everybody could have a try.
>
> First of all, why a new build system? Wasn't the old Makefile-based
> built system working well enough? Well, it was most of the time, but it
> also had a lot of problems:
>
> - The autoconf/configure way vs. Makefile-default.cnf:
>   I think most developers simply used the Makefile-default.cnf setup
>   without taking care of configure.ac - quite understandable, since
>   editing configure.ac requires knowledge about the autoconf "madness",
>   you have to struggle with M4 and portable shell script programming,
>   and that's no fun at all.

I think configure & proprietary IDEs are about the only reason to use
CMake.

As long as we don't need to add new additional deps, configure stuff doesn't
need to be touched.

IDE support could be added by people using IDEs, there are so many
IDEs out there (Eclipse, KDevelop, Anjuta...).


>   However, most users are used to run "./configure ; make ; make
>   install" to install a software (and actually also complain if there
>   is no configure script, I had this situation in the past...), and the
>   configure step is also required for compiling on most non-Linux
>   systems.
>   So we had the situation that developers and users use different steps
>   to configure and compile the emulator ... not a very good solution
>   since the configure script often dropped behind the
>   Makefile-default.cnf evolvement.
>
> - Managing dependencies between header files and C files is quite a
>   pain and very error prone with pure Makefiles. It's working most of
>   the time in Hatari now, thanks to the "make depend" target, but there
>   are still situations where people complain an the mailing list that
>   Hatari does not compile anymore - and we've got to tell them that a
>   simply "make distclean" inbetween should fix the issue.

As you say, works now. :-)

I think distclean issue is there also with CMake?


> - Our Makefiles only worked with GNU-Make, other derivates like
>   BSD-make did not work.

Is this really an issue?  GNU make is so old and standard that it's
about universal (maybe not under name make but gmake on some
proprietary platforms).


> - Our build system did not support out-of-source builds (i.e.
>   generating the object files out of the source tree), which is helpful
>   for cross-compiling and distributors.

This could be added if needed I think.  But first it would need
some description how that should work.  Just obj files elsewhere
or everything?


> - The Mac OS X build system is a separate build system. It
>   does not get updated automatically when we add or remove a a
>   .c file in the main Makefiles. So OS X users often complain
>   about the non-working Xcode files.

IMHO for things like that it would be better to use the socket
interface instead of building things directly to Hatari.  Configuration
parsing could be make so that it offers a library & header for
the structs which can be used by those external GUIs.


> - Some people tried to compile Hatari on Windows with an IDE, without
>   using the Makefiles, for example with Code::Blocks or Visual Studio.
>   Most of them failed, being quite frustrated afterwards. I think we
>   could get a lot of more support from these users when we enabled
>   Hatari build for these IDEs, too.

They people should really complain to their IDE vendors that those IDEs
don't support building the huge amount of autoconf + GNU Make projects
out there...


> After being quite frustrated of this situation for quite a while, I
> recently came across CMake: http://www.cmake.org/
> CMake is a build system configuration environment, somewhat similar to
> what autoconf provides, but with multiple backends and much easier to
> use than autoconf:
>
> - It can generate Makefiles for make, project files for Visual Studio,
>   Code::Blocks and XCode.
>
> - It supports library and header file detection (similar to autoconf)
>
> - The Makefiles that CMake generates are really cool, they use colored
>   output, percentage indicator, proper header <-> .c file
>   dependencies, out-of-source builds, etc.

You can get colored output for any gcc compilation by installing "colorgcc".

Percentage indicator of what?


> - The syntax of the CMakeList.txt files is likely new to everybody, but
>   it is very easy to learn. I've never run into big problems here, and
>   the cmake manual is quite helpful (and not as chaotic as the various
>   autotools info-pages)

From what I've read, the language is uglyish and changes from time to time
(needed changes to support KDE if I remember right).  If it would use some
real languge (e.g. Lua what they've considered) instead of their own hack,
and it mature a bit more, I could try it out.   Maybe in a year or two..


> All in all, it solves most of the problems that I've mentioned above.
>
> Now, I'd like to ask you to try it out, so we can discuss here on the
> mailing list whether we should switch complete to CMake or stay with
> the old build system.
> For testing it, please install "cmake", create an empty folder
> somewhere and run cmake from there with the path to the sources as
> argument. For example, if you are at the top of the sources:
>
>   mkdir obj
>   cd obj
>   cmake ..
>
> (you could also run "cmake ." from the top of the sources, but this
> would currently overwrite the old Makefiles, which is certainly not
> what you want)
> It should configure the build process and generate Makefiles. Then you
> can run "make" (and "make install") to build Hatari.
> Then please have a look at the CMakeLists.txt files to see whether you
> like the CMake syntax or not (and compare it to configure.ac ;-) )

I prefer using just pkg-config in Makefile now that pkg-config is actually
used by nearly everything (including X) on Linux...

It cannot find Windows missing standard (POSIX) functions though.


	- Eero



More information about the hatari-devel mailing list