Summary: | [Qt] SQLite support no longer optional, required even in minimal Qt build | ||
---|---|---|---|
Product: | WebKit | Reporter: | Robert Hogan <robert> |
Component: | Tools / Tests | Assignee: | QtWebKit Unassigned <webkit-qt-unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | Blocker | CC: | abecsi, hausmann, ismail, jturcotte, laszlo.gombos, noam, ossy |
Priority: | P1 | Keywords: | Qt |
Version: | 528+ (Nightly build) | ||
Hardware: | Other | ||
OS: | All |
Description
Robert Hogan
2010-03-12 14:31:46 PST
On Windows, to have SQLite supporte enabled in QtWebKit you must either: - Build QtWebKit within the Qt source tree (i.e. the sources must be in src/3rdparty/webkit and built through configure/make) - Have the SQLITE3SRCDIR environment variable set to the source directory of sqlite (which can be the one in Qt/src/3rdparty/sqlite) On most qtwebkit windows trunk dev setup, none of these conditions are met, so requiring SQLite would make the standard build steps a bit more complicated on Windows. (In reply to comment #1) > On Windows, to have SQLite supporte enabled in QtWebKit you must either: > - Build QtWebKit within the Qt source tree (i.e. the sources must be in > src/3rdparty/webkit and built through configure/make) > - Have the SQLITE3SRCDIR environment variable set to the source directory of > sqlite (which can be the one in Qt/src/3rdparty/sqlite) > > On most qtwebkit windows trunk dev setup, none of these conditions are met, so > requiring SQLite would make the standard build steps a bit more complicated on > Windows. The third option that currently applies when I build windows package is that QTDIR happens to be set, and so sqlite3.c from QTDIR/src/3rdparty/sqlite gets compiled in. Perhaps shipping a copy of sqlite3.c is what we have to do with the packages, to fall back to when there is no system library :-( I think it should block QtWebKit-2.0 release, because it is a build brake. I think a better fix is to make the GEOLOCATION guard proper - see https://bugs.webkit.org/show_bug.cgi?id=25756. (In reply to comment #4) > I think a better fix is to make the GEOLOCATION guard proper - see > https://bugs.webkit.org/show_bug.cgi?id=25756. That sounds right. Robert, what do you think? (In reply to comment #5) > (In reply to comment #4) > > I think a better fix is to make the GEOLOCATION guard proper - see > > https://bugs.webkit.org/show_bug.cgi?id=25756. > > That sounds right. Robert, what do you think? Looks like Laszlo has done all the hard work and this bug can be closed once his patch is landed. |