Difference between revisions of "Database/Drivers/MySQL Native/Building With CMake"
(→Pre-generated files) |
|||
| Line 20: | Line 20: | ||
Consequently, this approach would work for Sun's build environment only, where OOo is built against a fixed machine configuration. | 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 === | ||
Revision as of 14:10, 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.
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.
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.
