Custom Query (301 matches)

There is a decision to distribute Qt only in RPM format. Two reasons:

1. WarpIn? and RPM are competing and should not co-exist as this creates a mess (file duplication, version conflicts and so on) on the user machine.

2. Doing it RPM-only will motivate users to switch to RPM ASAP as Qt is usually a highly wanted piece of software.

With 4.6.3, qmake places the generated ui_*.h files in the objects directory. While appears to be a good choice not to mix the generated files with the source, it caused a compile break here. In order to fix this, I had to add "." to the compiler's include path. Is that working as designed ?

It turns out, that these two database plugins can be build quite nicely. We should at least offer "configure" support for them (if not even ship binary versions). Here is, what I did to compile them:

Added to src\plugins\sqldrivers\mysql\mysql.pro

    os2 {
        TARGET_SHORT = qmysql
        LIBS += -lmysqlclient_r -lpthread -llibssl -llibcrypto
    }

Then run:

qmake "INCPATH+=<mysql_path>\include\mysql" "LIBPATH+=<mysql_path>\lib"

make

I couldn't find a clear statement, if the "reentrant" version of the MySQL client library is really necessary when used in the context of a Qt plugin. If not, it would remove the dependency from pthread.

For PostgreSQL the change in src\plugins\sqldrivers\psql\psql.pro could look like this:

   os2 {
       TARGET_SHORT = qpgsql
       LIBS += -llibpq -llibssl -llibcrypto
   }

And the qmake/make command being similar.

In both cases the resulting plugins depend on OpenSSL. I'm not sure, if we should make the selection of the SSL libs a config option so that the user can also build the plugins with SSL linked in statically. But as I wrote in #167, I would prefer the DLL approach.

BTW, I did a quick test only with MySQL. I don't have PostGreSQL running here.