Database/Drivers/MySQL Native/Building With CMake
Contents
Problem
Both Connector/C++ (called C/Cpp) and Connector/C (called C/C; formerly known as libmysql) are usually built using cmake.
It's hardly possible to simulate this with dmake
: Both projects make use of cmake
's configuration features, in that a template file is processed by cmake
, and converted into an actual header/source file. In case of C/Cpp, this template file is pretty simple, and can easily be replaced with a hard-coded one.
However, in case of C/C, the templates are pretty complex, containing lot of checks for certain system headers and functions. Here, simulating cmake
functionality with dmake
is up to impossible.
Thus, we need a solution how to build C/C and C/Cpp during an OOo build. Unfortunately, we cannot simply assume cmake
being present on the build system: It currently is not a pre-requisite for compiling OOo.
Possible Solutions
In C/C, two files are affected by the cmake
conversion: include/mysql_version.h
and include/my_config.h
. The latter of the two is not used on Windows. The former (mysql_version.h
) is pretty straight forward, it could be generated from mysql_version.h.in
using a perl script, for instance.
So, what we really need to find a solution for is the generation of my_config.h
during building C/C.
Pre-generated files
One possible approach is to once generate the my_config.h
file for every supported platform, commit it, and during the build, just copy it to its expected location.
The main disadvantage, as I see it, is that "platform" in OOo's build environment terminology is a way too broad term: Different systems, all subsumed under (say) unxlngi6.pro, would result in different versions of my_config.h
. So, in reality one would need to have one file per concrete system where OOo is built on, which of course is impossible.
Consequently, this approach would work for Sun's build environment only, where OOo is built against a fixed machine configuration.
Making cmake a pre-requisite
Another approach would be to simply make cmake
a pre-requisite for any OpenOffice.org build. So when building C/C, cmake
could be ran, and would produce all necessary files. (The subsequent "real" build could then be done with dmake
, if required/desired.)
configure
would check for the presences of cmake
, optionally with a --with-cmake=...
switch. If cmake
is not found, configure
would bail out.
Probably, all of this would happen only when building C/OOo (and thus building C/Cpp, and thus building C/C) is enabled, so people who do not (want to) have cmake
on their system can simply disable C/OOo.
(C/OOo is "Connector/OpenOffice.org", which is the MySQL terminology for what we on the OpenOffice.org side call MySQL Native Driver.)
The disadvantage here is that this does not work well for environments where different OOo versions need to built on the same machine. In particular, Sun-Hamburg's environment would be affected: Over time, different OOo versions (branches) might need different versions of cmake
. Maintaining all those in a common environment, without interfering with each other, in a way that still all branches can be built, might turn out to be a nightmare.
Building cmake from scratch
Finally, cmake
could be treated like any other external project: We could create a dedicated top-level module, containing a download folder with the source tarball, which is to be extracted and build during the OOo build. Then, the executable (and all support files, for instance the ones which are usually installed to /usr/local/share) could be delivered to SOLVER, and employed when building C/Cpp.
Since here cmake
would be part of SOLVER, this probably would avoid problems on machines "multi-environment" machines like those Sun-Hamburg uses.
Of course, the approach could be combined with the previous one, by introducing a --with-system-cmake
switch to configure
.