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

From Apache OpenOffice Wiki
Jump to: navigation, search
(New page: Both Connector/C++ (called C/Cpp) and Connector/C (called C/C; formerly known as libmysql) are usually built using [http://www.cmake.org cmake]. It's hardly possible to simulate this with...)
 
 
(15 intermediate revisions by one other user not shown)
Line 1: Line 1:
 +
__TOC__
 +
 +
== Problem ==
 +
 
Both Connector/C++ (called C/Cpp) and Connector/C (called C/C; formerly known as libmysql) are usually built using [http://www.cmake.org cmake].
 
Both Connector/C++ (called C/Cpp) and Connector/C (called C/C; formerly known as libmysql) are usually built using [http://www.cmake.org cmake].
  
 
It's hardly possible to simulate this with <code>dmake</code>: Both projects make use of <code>cmake</code>'s configuration features, in that a template file is processed by <code>cmake</code>, 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.
 
It's hardly possible to simulate this with <code>dmake</code>: Both projects make use of <code>cmake</code>'s configuration features, in that a template file is processed by <code>cmake</code>, 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 <code>cmake<code> functionality with <code>dmake</code> is up to impossible.
+
However, in case of C/C, the templates are pretty complex, containing lot of checks for certain system headers and functions. Here, simulating <code>cmake</code> functionality with <code>dmake</code> 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 <code>cmake</code> 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 <code>cmake</code> conversion: <code>include/mysql_version.h</code> and <code>include/my_config.h</code>. The latter of the two is not used on Windows. The former (<code>mysql_version.h</code>) is pretty straight forward, it could be generated from <code>mysql_version.h.in</code> using a perl script, for instance.
 +
 
 +
So, what we really need to find a solution for is the generation of <code>my_config.h</code> during building C/C.
 +
 
 +
=== 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.
 +
 
 +
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 <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.
 +
 
 +
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 <code>cmake</code> a pre-requisite for any OpenOffice.org build. So when building C/C, <code>cmake</code> could be ran, and would produce all necessary files. (The subsequent "real" build could then be done with <code>dmake</code>, if required/desired.)
 +
 
 +
<code>configure</code> would check for the presences of <code>cmake</code>, optionally with a <code>--with-cmake=...</code> switch. If <code>cmake</code> is not found, <code>configure</code> 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 <code>cmake</code> 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 <code>cmake</code>. 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, <code>cmake</code> 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 <code>cmake</code> would be part of SOLVER, this probably would avoid problems on machines "multi-environment" machines like those Sun-Hamburg uses.
  
Thus, we need a solution how to build C/C and C/Cpp during an OOo build.
+
Of course, the approach could be combined with the previous one, by introducing a <code>--with-system-cmake</code> switch to <code>configure</code>.
 +
[[Category:MySQL]]

Latest revision as of 21:40, 15 December 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.

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.

Personal tools