[Interest] Proper way of testing whether Qt is being used by a program

[BRM]

> From: Shriramana Sharma <samjnaa at gmail.com>

> To: Konstantin Tokarev <annulen at yandex.ru>
> Cc: "interest at qt-project.org" <interest at qt-project.org>
> Sent: Tuesday, August 14, 2012 7:59 AM
> Subject: Re: [Interest] Proper way of testing whether Qt is being used by a program
> 
> On Tue, Aug 14, 2012 at 4:33 PM, Konstantin Tokarev <annulen at yandex.ru> 
> wrote:
>>  If you still want to switch them by #ifdef, you should consider using 
> custom define
>>  passed by user or configuration option of your library.
> 
> Hi thanks for your reply.
> 
> Basically I'm writing the library primarily for my own personal use
> where I'll be writing a Qt application that links to this library, so
> I thought it would be useful to use QList QString etc. (I didn't
> mention QString etc in my previous post.) But for the library to be
> potentially useful to others also, I want to make it so that those who
> don't use Qt for their GUI or other stuff don't need to use it just to
> link to my library, so I thought I should allow the generic C++
> classes.
> 
> So would you advice to use the generic C++ classes anyway?
> 

As Rene Reucher suggested, it would be better to use a build time configuration option to enable/disable interfaces in the library.
That is:

"./configure --with-qt" type of build option would enable a Qt binding to be built with it; otherwise it just builds it with the STL interfaces.
For that matter, you could have an option to enable/disable the STL interfaces too.

In the end, you would be providing both and allow the programmer/library builder to decide which to enable.
Just make sure that however they build it it will work, and not be caught depending on something in the other build.

Of course, if you're making it as a shared library (*.so, *.dll) then you could just link Qt in the back-end and the configuration option is just a matter of what you provide to the programmer.

$0.02

Ben