On 18 December 2011 22:48, Roger Binns <rog...@rogerbinns.com> wrote:
> The preferred solution for most SQLite using developers is to include a > private copy of SQLite. You just add the single amalgamation source file > to your project and are no longer at the mercy of whatever goes on on the > platform. Roger, thanks for the portion of convincing notes. My hope is to be finally able to use a private copy of sqlite, what I actually have been doing in 2004-2008 or so. Then I switched to 'system' SQLite and only had no visible problems only because so far Kexi uses only basic features of sqlite3 and does not try to optimize its usage. While talking to Linux distributors a bit I've noticed their reasoning for refusing private copies, e.g. see comments posted under my blog entry http://blogs.kde.org/node/4156. While I understand this, SQLite is special case for the reasons you explained very well. It would save weeks of developing workarounds if only we could make some coordinated effort to turn these recommendations to something official in eyes of distributors and make them allow for exceptions in their rules. I mean for Linux, since deployment for Mac and Windows can be controlled. Another reason for wanting the private copy is specific approach to versioning in sqlite. The file format changed in areas relevant for most users, and without a bump in major version. Thus distributors unfortunately do not bump major version of libsqlite3.so, so in turn, there's not way to have two versions of 'system' sqlite3 installed side-by-side unless, e.g. to enable data migration tools. Private copies fix this as well. -- regards / pozdrawiam, Jaroslaw Staniek http://www.linkedin.com/in/jstaniek Kexi & Calligra (kexi-project.org, identi.ca/kexi, calligra-suite.org) KDE Software Development Platform on MS Windows (windows.kde.org) _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
