> -----Original Message-----
> From: Kristian Nielsen [mailto:knielsen@stripped]
> Sent: Thursday, November 12, 2009 9:40 PM
> To: Vladislav Vaintroub
> Cc: 'Internals List'
> Subject: Re: Cross-platform build with CMake
> I think the main problem to keep in mind with CMake is that it is not
> to build a project using CMake without first installing CMake. This is
> contrast with autotools; it _is_ possible to build MySQL from source
> without installing autotools on the build machine (just like bison also
> is not
This is true. Though, it is a small problem - Linux distros have cmake
(I'd guess KDE helped a lot in promoting it), OpenSolaris has it.
Binary versions for wide range of platforms are downloadable and small in
size and at the end, you can build it yourself from source, C++ compiler
is the only prerequisite.
> I seems to me that having a single build system outweights this
> disadvantage. But it is something to keep in mind once the switch to
> CMake is made; one should then be somewhat conservative with requiring
> versions of CMake, so that the required version is easily available
> also on
> older Linux distributions eg.
Currently it requires Cmake 2.6 (2 years old release) but at least on Ubuntu
I have seen 2.4.7. So, I built from source. I think it would also be
possible to get
it using some PPA.
> I think the ability for as many as possible to easily build from source
> is quite important.
> > Quite important: autotools are not killed and CMake will peacefully
> > with autotools at least for some time. Speaking about the _long_ term
> I do
> > not see how
> > having 2 build systems would simplify development (so if CMake
> appears to be
> > good, and
> > people will like it my hope is that we can get rid of autotools)
> Yes, that sounds like a good plan.
> > 4. (Optional) configure build options
> > - From command line :
> > cmake . -LH # lists options
> > cmake . -DWITH_INNOBASE_STORAGE_ENGINE=1 -
> DWITH_ARCHIVE_STORAGE_ENGINE=1 #
> > set options
> Ok, so this replaces the win/configure.js ? Good!
Yes, native CMake'ish way to specify options. win\configure.js is
not likely to run on Unix :)
> I guess a main part of the work now will be to implement all of the
> options from the autotools build system for CMake?
The biggest parts were actually system checks, we have "many"
including admittedly some silly ones (HAVE_MEMCPY).
Re options : I think I do have most important options, but I skipped some,
files are always big (64 bit file offsets), something like --with-low-memory
I ignored fully.
If you do
cmake . -LAH it will also list "advanced options".
I have declared some rarely used options "advanced", so people are not
overwhelmed with options by default..
There will be something that I have missed (and if you find it, please tell)
> them, there
> is probably a lot of old cruft in there that could be cleaned up.
> One suggestion would be to use the ./configure style options to be more
> similar with the existing build system. It was a bit of a mistake when
> I wrote
> the original CMake stuff (with Reggie) that the Windows options got
> names from the autotools options :-(. Seems like now would be a good
> time to
> fix this?
Hmm, Capitalizing (translating --with-something-cool to WITH_SOMETHING_COOL)
seems to be actually widely used - KDE is be doing the same, and this looks
general CMake'ish style to have options in capitals.
I still need to check exactly how I handle plugins
(WITH_XYZ_STORAGE_ENGINE works 100%, whether WITH_PLUGINS=a,b,c or
work I'm not sure about).
Besides capitalizing, I think there is not much difference. Windows did not
as many options as Unix, besides storage engines it had now-obsolete __NT__.
Anything I have missed?
> > - You can build mysql exactly the same way you did prior, that is
> > BUILD/autorun.sh && ./configure && make
> > builds with cmake, if cmake is installed. Though, it does not produce
> > projects
> > and does not have out-of-souce build support
> Does this really build with CMake?
If cmake is installed, yes. If you look at ./configure, it chooses
whether to run original autotools generated shell script or cmake,
based on availability of cmake.
Also look at changes in BUILD/autorun.sh, BUILD/choose_configure.sh,
cmake/configure.pl, this should explain the magic better.
I do not know if this hack passes the review.
The primary reason I have done it this way, was to get it my tree tested on
pushbuild without changing pushbuild. Builds in this tree now sometimes
run with autotools-generates script and sometimes with cmake, if cmake is in
PATH (some Linux and Solaris machines in PB have cmake in PATH already, huge
thanks to Danny)
> How does this able to pass all of the ./configure options from the m4
> into CMake?
A very crude cmake/configure.pl called from top-level ./configure
translates all --whatever to -DWHATEVER=1 and starts cmake at the end.