Difference between revisions of "Database/Drivers/MySQL Native/Building With CMake"

From Apache OpenOffice Wiki
Jump to: navigation, search
(Making cmake a pre-requisite)
(Pre-generated files)
Line 19: Line 19:
 
=== Pre-generated files ===
 
=== Pre-generated files ===
  
One possible approach is to *once* generate the <code>my_config.h</code> file for every supported platform, commit it, and during the build, just copy it to its expected location.
+
One possible approach is to ''once'' generate the <code>my_config.h</code> 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 <code>my_config.h</code>. So, in reality one would need to have one file per concrete ''system'' where OOo is built on, which of course is impossible.
 
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 <code>my_config.h</code>. So, in reality one would need to have one file per concrete ''system'' where OOo is built on, which of course is impossible.

Revision as of 13:02, 9 March 2009

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.

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. (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.

Personal tools