Vladislav Vaintroub <wlad@stripped> writes:
> I have created a WL#5161 with a task dedicated to supporting a unified build
> based on CMake (http://www.cmake.org/). CMake has been in use for 3 years to
I think a plan for a single build system is a really good thing. Thanks!
CMake does seem a good candidate for this, for the reasons you mentioned. I
learned that KDE builds with CMake, which makes me believe that CMake is now
sufficiently flexible for this task (it was not when the original CMake files
for Windows build were made).
I think the main problem to keep in mind with CMake is that it is not possible
to build a project using CMake without first installing CMake. This is in
contrast with autotools; it _is_ possible to build MySQL from source tarball
without installing autotools on the build machine (just like bison also is not
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 only
CMake is made; one should then be somewhat conservative with requiring new
versions of CMake, so that the required version is easily available also on
older Linux distributions eg.
I think the ability for as many as possible to easily build from source is
> Quite important: autotools are not killed and CMake will peacefully coexist
> 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!
I guess a main part of the work now will be to implement all of the options
from the autotools build system for CMake? Well maybe not _all_ of 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 different
names from the autotools options :-(. Seems like now would be a good time to
> - 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 Xcode
> and does not have out-of-souce build support
Does this really build with CMake?
How does this able to pass all of the ./configure options from the m4 stuff
Or maybe I misunderstood.
Looks like a lot of good work was done here, great!
Hope this helps,