[hatari-devel] CMake build system

Thomas Huth huth at users.berlios.de
Wed Jan 20 22:31:25 CET 2010


On Wed, 20 Jan 2010 00:57:04 +0200
Eero Tamminen <eerot at users.berlios.de> wrote:

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

Don't forget the automatic header file dependencies... the current
setup in Hatari works in most cases, but it's far from being bullet
proof. With CMake, we would get much better dependency generation, I
think.

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

Well, portaudio is still missing in configure.ac. Someone should add it
there before the next release...

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

The problem is here, that you need somebody who actively maintains the
project files for these IDEs - or you'll end up with something like the
Xcode project in our repository that always lacks behind.
With CMake you would get this support for free - considering that the
project files would really work ;-)

> I think distclean issue is there also with CMake?

The Makefiles from cmake do not have a distclean target by default. But
I think you can define one on your own.

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

It's not really a big problem, but from time to time there are always
people who are trying to build Hatari with a non-GNU make... that's why
the configure script spills out this message about "gmake" at the end.

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

I suggest to do it just like the standard "automake" way, since this
is what people suggest: the object file tree is placed to the folder
from wherever you call the "configure" script from.
But I guess the Makefiles would become more complicated and less
maintainable by this, so I doubt that you want to add and maintain this
feature "manually".

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

Building Hatari for Mac OS X is not just about adding the GUI. The
build system has to take care of the special libraries formats on Mac
OS X (.dylibs versus Frameworks) and it has to bundle the application
into a certain folder structure with some additional meta information
files. It might be possible to do this manually from within a Makefile,
too, but it is much easier to do with Xcode.

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

autoconf is IMHO a big pain. Supporting this in an IDE would be a huge
discrepance to the idea that an IDE should ease development...

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

Oh, come on, Eero, just give it a try. Simply do an "apt-get install
cmake && cmake . && make" and you'll see.

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

Well, I think the language is quite easy to use. At least it is _much_
better than the M4 + shell script mix that you have to use for autoconf!

And by the way, normal Makefile syntax is also very crappy and error
prone - it's just that we are used enough to it to not notice this
anymore... just try to remember your first steps with Makefiles...
"What, I have to use TABs here? Why can't I use spaces? ... etc."

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

pkg-config is ok... as long as you _only_ support Linux. As soon as you
try to support other Unix-like operating systems as well, you need
something like a configure script, sooner or later.

 Thomas



More information about the hatari-devel mailing list