Difference between revisions of "Database/Drivers/MySQL Native/Building With CMake"
(→making cmake a pre-requisite)
(→building cmake from scratch)
|Line 35:||Line 35:|
=== building cmake from scratch ===
=== building cmake from scratch ===
Revision as of 14:38, 6 March 2009
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.
In C/C, two files are affected by the
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.
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.
This has several disadvantages. For one "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.
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
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.
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