[Qt-interest] subclassing Sql drivers (linking issue)

[Bill King]

I think the solution you hit on, of replicating the .pr(i/o) files, and
including the source code is the best solution at this point.
Those projects won't be changing in a hurry (except for maybe moving the
headers to _p.h files. That'll be a bit off yet, as there's a few major
bugs I'm working on currently.

On 02/24/2010 05:31 AM, ext André Somers wrote:
> Hi Thiago,
>
> Thanks for your explanation; it makes a lot of sense.
>
> What I am trying to do is basically extend the Qt SQL drivers to support
> data definition language statements through the QSqlDriver::sqlStatement
> (along with some other extensions). For this, I have written a template
> class that uses the template argument as the class to derive from. This
> template class defines and implements most of the additional stuff needed,
> and it is then specialized per concrete driver. I end up with something like
> this:
>
> Template<typename SqlDriverBase>
> ExtendedSqlDriverBase : public SqlDriverBase {
> ...
> }
>
> ExtendedMySqlDriver: public ExtendedSqlDriverBase<QMYSQLDriver> {
> ...
> }
>
> For this to work, I need to be able to inherit from the existing drivers.
> Including the qt code into my own driver code works, but it would be nicer
> if I would be able to link against them. Alternatively, I could go for an
> encapsulation approach instead of subclassing. That would however require my
> driver to load the plugin and get an instance of the driver independently
> from QDatabase. Might work too, but not too nice either. Any other
> suggestion that is more elegant? I really prefer not to copy any Qt code
> into my own project, or modify the Qt code directly, as that will quickly
> become a maintenance problem. I like being able to just install a new SDK
> and be done :-)
>
> André
>
> -----Oorspronkelijk bericht-----
> Van: qt-interest-bounces at trolltech.com
> [mailto:qt-interest-bounces at trolltech.com] Namens Thiago Macieira
> Verzonden: dinsdag 23 februari 2010 19:26
> Aan: qt-interest at trolltech.com
> Onderwerp: Re: [Qt-interest] subclassing Sql drivers (linking issue)
>
> Em Terça-feira 23 Fevereiro 2010, às 17:27:22, Andre Somers escreveu:
>   
>> Thiago Macieira wrote:
>>     
>>> Em Terça-feira 23 Fevereiro 2010, às 16:22:28, Andre Somers escreveu:
>>>       
>>>> Andre Somers wrote:
>>>>         
>>>>> Andre Somers wrote:
>>>>>           
>>>>>> Hi,
>>>>>>
>>>>>> I am trying to extend the Qt SQL drivers to add some 
>>>>>> functionality. I have the thing compiling, but I run into a 
>>>>>> problem when linking. I get
>>>>>>             
>>>       
>>>>>> lots of "undefined reference" errors like these:
>>>>>>             
>>> Change Qt code and recompile the driver.
>>>
>>> The driver is not a library. You cannot link to it.
>>>       
>> Weird, since the project file says it is:
>>
>> odbc.pro sets the target, and includes qsqldriverbase.pri 
>> sqldriverbase.pri includes qpluginbase.pri qpluginbase.pri contains 
>> TEMPLATE = lib
>>
>> That would suggest that the driver *is* a lib. The mere fact that it 
>> results in a .dll (on windows) also suggests this.
>>     
> Not really. It's not a library, it's a plugin.
>
> In all platforms Qt supports, libraries and plugins are both dynamically-
> loadable libraries (DLL, dylib) / shared objects (so) -- it's the same
> concept with different names. (The only one where it wasn't the case was Mac
> OS X 10.2 and earlier, but those are not supported)
>
> The difference between a library and a plugin is the interface that they
> export. Especially on Windows, where no symbols are exported unless
> explicitly marked so (__declspec(dllexport)).
>
> For a library, besides the DLL you're going to find headers installed, which
> contain the public interface of that library. All such classes are properly
> exported (Q_CORE_EXPORT, Q_GUI_EXPORT, etc.) and usually documented. The
> same applies to your libraries as well, if you're on Windows -- on other
> platforms, qmake doesn't impose this on you.
>
> For a plugin, however, there are no public headers. The classes are not
> exported, so the DLL's symbol table is almost empty. What it will contain,
> however, is a simple "plugin entry point": a C function that can be found
> via dlsym or GetProcAddress. The plugin loader code will then call that
> function and obtain an object that can be used (for Qt plugins, the plugin
> "instance").
>
> A plugin usually implements an interface defined in a library. The Qt SQL
> drivers, for example, all derive from QSqlDriver. The rest of the code
> interacts with the plugin only by the interface defined in this library.
>
> Now, what I do find weird is that QtSql has headers for each plugin. Some of
> the classes are exported, some aren't. And none of them is documented. I'm
> wondering if those headers should be _p.h and not made public.
>
> Bill, do you have an opinion?
>
>   
>> Still, I managed to solve this a bit less elegantly by including the 
>> relevant parts of these .pro files into my own one, pulling in the Qt 
>> driver code into my own drivers. This frees me from having to 
>> re-modify the qt drivers time and time again with each qt version. At 
>> least as long as their .pro files remain stable... At least the thing 
>> compiles and links now, and the qt plugin mechanism seems to load the
>>     
> driver OK.
>   
>> Next up is making sure it actually works of course...
>>     
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>   Senior Product Manager - Nokia, Qt Development Frameworks
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
>
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest
>   


-- 
Bill King, Software Engineer
Qt Development Frameworks, Nokia Pty Ltd
Brisbane Office