Thanks to Alex Burton's prompting I'm considering replacing the
current Bakefile based build system with something else.
Bakefile does many things right:
- It is not a build system in and of itself. It is a Makefile and
project file generator, which means MySQL++ end users do not need
Bakefile to build MySQL++. They use the native tools they already have
and know. I very much want to retain this feature.
- It builds and runs on the systems I use to create distribution
tarballs. Because Bakefile is not a prerequisite to building from a
distribution tarball, its portability problems are largely immaterial.
- Only one MySQL++ platform has a large chunk of end users with a good
reason to rebake MySQL++: Windows, since the distributed project and
Makefiles necessarily have hard-coded C API paths in them. But,
Bakefile has an official binary installer package for Windows, so once
again, there is no real portability or availability problem.
- It ships with enough project and Makefile generators that it covers
every common platform.
I am considering replacing Bakefile because it is not without problems:
- It doesn't support MSBuild flavored Visual Studio projects, so people
have to convert the Visual Studio 2008 projects to the version they're
actually using, a process that doesn't always go as smoothly as it
should. (Ultimately, this is Microsoft's fault, but we have to deal
with the fallout of their failure to do the conversion properly.)
- Ugly, verbose XML syntax
- Extensibility requires modifying the local Bakefile setup. Since I
don't want to ship Bakefile extensions, it means it is effectively
inextensible short of getting patches into upstream.
- Uncommon, hence not available everywhere in binary form, and it
doesn't build from source everywhere. If Python 2.x ever dies out,
Bakefile will likely die, too.
So, What Next?
The SCons wiki has a great comparison of competing build tools.
Having read through it, I still think only SCons and CMake are suitable
replacements for Bakefile, as used by MySQL++. Every other alternative
either has too many limitations or problems.
Of those rejected, only qmake looks like it might actually be a good fit
for a Bakefile replacement. The only reason it isn't under
consideration is that I ran out of time while evaluating CMake and SCons
to study qmake.
If anyone reading this thinks I have unfairly overlooked another
suitable alternative, please let me know about it.
- Clean, powerful Python based DSL.
- Because the SConstruct file is Python, any code we'd have to write to
port over all the features we get in the current build system will
travel with MySQL++. (This is why effective inextensibility is on the
list of Bakefile cons above.)
- Runs the same on all platforms.
The current MySQL++ build system abstracts the platform differences at
the Bakefile level, but because it generates native Makefiles and
project files, different platforms have different features. e.g. Debug
vs Release builds on VS and Xcode, but not on MinGW or Autoconf. Or
easy toggling of threads and static libraries on Autoconf, but not on
the other platforms.
- We've got a big leg up on the conversion, thanks to Alex Burton.
SCons Cons ons ns s () 
- It is the entire build system. This means it is a prerequisite to
building MySQL++ from source for everyone except perhaps the Visual
Studio users. (See next item.) With Bakefile and CMake, only core
developers or those who want to hack on the MySQL++ build system need
the nonstandard tool. I'm not sure I can accept this.
- The front page of the SCons web site says there is a way to make it
generate VS project files, but I don't see a section on it in the user
guide. Everything I've seen on this talks about Visual Studio 6 vs
7, which is ancient history. I care about VS2003-2008 vs VS2010+. If
we can't get it to spit out VS2010 files at minimum, there isn't much
point in switching to SCons, since I don't want to go telling Windows
users they have to install SCons first, and that they have to build
MySQL++ from the command line. Some will be fine with that, but it's a
pretty anti-Windows stance to take.
- Because SCons replaces everything in the current build system, we'd
have to port all the autoconf tests and custom flags
(--enable-thread-check, --with-mysql, etc.) over to it, then document
all the build system changes. This will cause some work for the kind
souls who maintain the various MySQL++ binary packages.
- It is a make/project file generator like Bakefile, so normal end users
don't have to have CMake unless they want to do something atypical.
(e.g. set up out-of-tree builds on *ix systems.)
- MySQL and MariaDB 5.5+ use CMake. Clearly it has enough power to do
anything MySQL++ will ever need.
- Up-to-date Visual Studio support. It already has explicit support for
VS2013, which is only a few months old.
- Since it replaces Automake, does it make it harder to keep using
Autoconf? Will we be pushed into translating all the M4 tests and such
into CMake syntax?
- It replaces Libtool, which we switched to not that long ago to get
relocatable libraries on some embedded platform or other. (Adrian?)
Does CMake give suitable output here, or are we going to have to
manually integrate libtool into the CMake build on these platforms?
- None of the binary CMake packages I've tried (CentOS, Ubuntu, Brew,
Cygwin) include the Visual Studio generators! I don't know why everyone
is building CMake without these. We'll need them. Am I going to have
to build CMake from source just to get this?
- Fairly ugly syntax. Not as ugly as XML + Automake + M4 + shell, but
not nearly as clean as SCons/Python.
- Yet another programming language. Worse, yet another *specialized*
programming language that I will touch but once a year or so, so I will
never develop any real expertise. I already have Python skills, and
there's at least a chance I will have other calls on those skills, so my
SCons-fu won't deteriorate too much between uses.
- Probably not possible to extend-in-place, as with SCons. Like with
Bakefile, I think you have to build and install a plugin in the local
CMake setup, which means MySQL++ can never rely on doing this.
Thoughts? Comments? Suggestions?
 Can you tell I've been using FP languages lately?