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
- 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.
|• Evaluating Bakefile||Warren Young||25 Feb|