List:MySQL++« Previous MessageNext Message »
From:Warren Young Date:January 8 2014 4:10am
Subject:Next MySQL++ build system
View as plain text  
Thanks to Alex Burton's prompting[1] I'm considering replacing the 
current Bakefile based build system with something else.

Bakefile Pros
~~~~~~~~~~~~~

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.


Bakefile Cons
~~~~~~~~~~~~~

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[2]. 
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.



SCons Pros
~~~~~~~~~~

- 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 ()    [3]
~~~~~~~~~~~~~~~~~~~~~~

- 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[4].  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.


CMake Pros
~~~~~~~~~~

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


CMake Uncertainties
~~~~~~~~~~~~~~~~~~~

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


CMake Cons
~~~~~~~~~~

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



---------
Footnotes:

[1] http://lists.mysql.com/plusplus/9646

[2] http://www.scons.org/wiki/SconsVsOtherBuildTools

[3] Can you tell I've been using FP languages lately?

[4] http://www.scons.org/doc/production/HTML/scons-user/
Thread
Next MySQL++ build systemWarren Young8 Jan 2014
  • Re: Next MySQL++ build systemWarren Young8 Jan 2014
  • RE: Next MySQL++ build systemAlex.Burton8 Jan 2014
    • Re: Next MySQL++ build systemWarren Young9 Jan 2014
      • Re: Next MySQL++ build systemPau Garcia i Quiles9 Jan 2014
        • Re: Next MySQL++ build systemWarren Young9 Jan 2014
          • Re: Next MySQL++ build systemPau Garcia i Quiles9 Jan 2014
            • Re: Next MySQL++ build systemWarren Young9 Jan 2014
  • Re: Next MySQL++ build systemPau Garcia i Quiles8 Jan 2014
    • Re: Next MySQL++ build systemWarren Young9 Jan 2014
      • Re: Next MySQL++ build systemPau Garcia i Quiles9 Jan 2014
        • Re: Next MySQL++ build systemWarren Young9 Jan 2014
          • Re: Next MySQL++ build systemPau Garcia i Quiles9 Jan 2014
            • Re: Next MySQL++ build systemWarren Young9 Jan 2014