Review Request: SQLite version handling improvements (FindSqlite macro)
Jaroslaw Staniek
staniek at kde.org
Fri Feb 5 20:29:17 GMT 2010
> On 2010-02-05 18:38:49, Alexander Neundorf wrote:
> > I object to adding a _MIN_VERSION variable.
> > Since CMake 2.6 find_package() supports specifying the required version, we should use this instead.
> > So you can do e.g.
> > find_package(Foo 1.2.3)
> >
> > and inside the find-module the variables Foo_FIND_VERSION (the whole specified version string) Foo_FIND_VERSION_(MAJOR|MINOR|PATCH) (the three components, if not all components are specified the ones which were left away default to "0") can be tested, e.g. using if( ${Foo_FIND_VERSION} VERSIONGREATER ...) etc.
> >
> > This is done e.g. in FindQt4.cmake, FindKDE4Internal.cmake and FindEigen2.cmake in kdelibs.
> >
> > Alex
> >
Alex, thanks for the review!
I agree with the comment. Furthermore it's a bit weird that I moved out of using system SQLite - I plan to maybe blog about this: SQLite is not packgeable in general sense anymore. This is because there are many compile-time switches, so many not-fully compatible versions of SQLite can be found in particular distros.
While I think I have to fix the FindSqlite script, I won't use it. I am also thinking about having a copy of SQLite moved from Kexi into kdesupport, with sane build defaults. With lib name like libksqlite of course. Then something like FindKSqlite, far simpler, would be used within KDE.
- Jaroslaw
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2772/#review4076
-----------------------------------------------------------
On 2010-01-30 23:54:24, Jaroslaw Staniek wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2772/
> -----------------------------------------------------------
>
> (Updated 2010-01-30 23:54:24)
>
>
> Review request for kdelibs and Alexander Neundorf.
>
>
> Summary
> -------
>
> The feature set differs from version to version in case of SQLite. Distributions do not allow to install many versions of SQLite side-by-side, so applications that use SQLite without embedding its source code need to carefully check for features available. Otherwise, for example, the files modified with SQLite can loose silently backward compatibility. To make the version tracking easier, two input variables are used:
>
> * SQLITE_MIN_VERSION - e.g. "3.6.16", if defined, older SQLite versions will not be accepted
> * SQLITE_RECOMMENDED_VERSION - "3.6.22", if defined, warning will be displayed for older SQLite versions
>
> This way, checks can be performed earlier - at configure stage.
> In addition, version checking is independent of pkg-config tool, so it works on MS Windows in the same way as on Unices.
>
>
> Diffs
> -----
>
> /trunk/KDE/kdelibs/cmake/modules/FindSqlite.cmake 1082620
>
> Diff: http://reviewboard.kde.org/r/2772/diff
>
>
> Testing
> -------
>
> One of the main users of SQLite, KOffice's Kexi, configures and builds fine. Behaviour of the new script is backward-compatible.
>
>
> Thanks,
>
> Jaroslaw
>
>
More information about the kde-core-devel
mailing list