Evaluating Bakefile

[Warren Young]

I've been evaluating Bakefile (http://bakefile.sf.net/) as a way to 
replace the automake and makemake build systems in MySQL++.  This has 
the potential to allow us to maintain a single input file from which we 
can generate all makefiles and project files for compilers we support. 
I intend to switch over to this new build system for MySQL++ v2.1 unless 
someone discovers a serious problem with it.

I've got basic functionality working on Linux and Windows with VC++ 
2003.  There are still problems to overcome, but at this point I'm 
confident that they can be fixed or worked around.

What I need from the MySQL++ user base are people to try building 
MySQL++ using this new system.  At the moment, you will need access to 
some kind of Unix or Linux box, as Bakefile doesn't play well with 
autoconf projects (like MySQL++) on Windows, even under Cygwin.  You 
only need Bakefile for generating the Makefiles and project files, 
though, so once you've done that, you can copy the results over to your 
Windows box, if you like.

If you want to play with this, you need to check out the "v2.1-bakefile" 
branch of MySQL++, like so:

	svn co svn://svn.gna.org/svn/mysqlpp/branches/v2.1-bakefile

Below is a list of things that aren't yet working.  Much of this is just 
a way for me to document to-do items for myself, rather than a 
solicitation for help.  That said, if anyone provides a patch for any of 
these, I'll be happy to receive it.

- Bakefile doesn't use the LIBS variable within Makefile.in.  This 
mainly affects portability to SysV Unices like Solaris: we detect the 
need for -lnsl, -lsocket and -lm currently, and the results inform the 
LIBS value.  Rather than change Bakefile to support this, I think we 
should just change the autoconf tests that use this behavior.

- Thread handling needs work.  Currently, we're examining the MySQL C 
library name to infer whether we need to build the program with thread 
support or not.  That won't work on Windows, at least.

- For VC++, Bakefile currently only knows how to build MSVC6 project 
files.  VS 2003 can of course upconvert these, but it implies to users 
that MySQL++ works with VC6, which it doesn't.  It'd be better if there 
were a VS 2003 output option.  I'm toying with the idea that I'll just 
upconvert the project files myself and ship those files with the 
distribution tarball rather than the VC6 ones.  It's a manual process, 
but it only takes a few seconds....

- I haven't yet tested with VC++ 2005.

- I need to test it on a wider variety of Linuces, and on OS X, too.

- The 'install' and 'tags' targets aren't yet working.

- The obvious way to handle examples/util.cpp leads to it getting built
separately for each example that links to it, due to the way Bakefile
sets up its output files.  We can get around this by building a static
library containing just util.o and linking the examples to it.  I just 
haven't bothered to do this yet.

- The autoconf target generates intermediate output files in the same 
directory as the source files.  That's a step backwards from automake, 
which hid stuff like that in .libs subdirectories.  It'd be nice to have 
that behavior again.

- There is no equivalent of automake's "maintainer mode" in Bakefile. 
This means that if you change files like lib/lib.bkl, the generated 
Makefiles won't have rules that automatically re-run bakefile to 
regenerate the Makefile.  This will require changes to Bakefile to fix 
it correctly.

- Bakefile's documentation needs a lot of help, which makes getting up 
to speed on it more difficult than necessary.  I've sent Bakefile's 
maintainer a lot of patches for this, but more are still needed. 
Outstanding problems right now are that the bakefile_gen mechanism is 
completely undocumented, and many Bakefile tags (<lib-path>, <include>, 
etc.) have no syntax examples.  If you can find existing Bakefile 
examples, you can figure out how to use these facilities, but since 
Bakefile isn't popular yet, this isn't much comfort.