[CMake] ActiveQt with CMake?

Stephen Kelly steveire at gmail.com
Wed Dec 5 11:34:29 EST 2012


Pau Garcia i Quiles wrote:

> On Wed, Dec 5, 2012 at 5:00 PM, Stephen Kelly
> <steveire at gmail.com> wrote:
> 
>> Pau Garcia i Quiles wrote:
>> > I would say most people are not using ActiveQt and CMake together,
>> > plain and simple.
>> >
>> > For the very few who do, they are probably only using the Qt
>> > application as a client (i. e. load an ActiveX component), not to write
>> > servers.
>>
>> Aha, and the implication is that in that case, the post-build steps such
>> as running with -dumpidl and creating the IDL type library are not
>> necessary. Is that correct?
>>
>> How does one do that? By using the QAxContainer module and not using
>> QAxServer? Are there any other post-build steps in that case at all?
>>
>>
> Yes, that's right.
> 
> When you want to use an ActiveX component (e. g. Adobe Reader), you embed
> it using a QAxContainer.
> 
> When you want to create an application that will be embeddable by other
> applications, you create a QAxServer.
> 
> Your application/library could use an ActiveX component and be itself an
> ActiveX component to be embedded for others (simple case: you create an
> ActiveX component which is an enhanced reader that "extends" Adobe
> Reader), but it's not really common. Even less common using Qt (you would
> typically use C++ or C# for this kind of task). And even less common if
> it's Qt using CMake, for starters because being Windows-only, it makes
> little sense (other than moving from one version of Visual C++ to another)
> to use CMake for that project instead of plain Visual C++ project. All
> that lumped together explains why we have never seen this.

Thanks for all that information.

> 
>> Are those macros needed and useful? Very much so . Adding them to FindQt4
>> > would certainly make sense to me, too.
>>
>> I'm sure if they get written they'll be sufficiently generic to target
>> both Qt versions without too much modification. However, if no one uses
>> ActiveQt with CMake, do we need to do that at all?
> 
> 
> I think those macros are not really hard to write and if those macros are
> not available, we can be sure no one will use ActiveQt with CMake for the
> next 8 years either :-)

Well, at least it seems to make sense to commit the Qt5ActiveQt patch even 
without the macros as they can be added later. I don't think I have the base 
knowledge (or inclination) to implement them myself.

Thanks,

Steve.




More information about the CMake mailing list