[Development] Distributing 3rd party closed source libs

[Lars Knoll]

On 31/10/16 10:08, "Development on behalf of Sean Harmer" <development-bounces+lars.knoll=qt.io at qt-project.org on behalf of sean.harmer at kdab.com> wrote:

>Hi,
>
>On 31/10/2016 00:48, Chris Gilbert wrote:
>> Greetings,
>>
>> We use both QT5 and the Autodesk FBX loader in our application - and we
>> would strongly prefer Qt to NOT link it in.
>>
>> There is a need quite often for us to update the Autodesk FBX SDK
>> asymmetrically to QT, and it would be preferable QT doesn't use it in
>> order to avoid potential conflicts.
>>
>> Also, I believe there is a provision in the Autodesk FBX library which
>> forbids inclusion in free/open source software.
>> (Anti-blender provision)
>>
>> As a result, I believe Blender and some other applications (UE4) have
>> done their own implementation, perhaps QT could borrow from that?
>
>Yeah, trouble with that approach is we are always chasing feature 
>support and we'd rather focus efforts elsewhere. The options look like:
>
>* Provide a precompiled plugin like Qt does for the mysql/postgres 
>database driver plugins but which requires the user to install the fbx 
>dll's.
>
>* Source only plugin to allow users to easily build it against the fbx sdk.
>
>* dlopen the fbx lib from a plugin.
>
>We do not intend to ship the fbx sdk or compile it in or link it 
>directly to Qt for the reasons you mention.

We’re facing the same problem in a couple of places in Qt. For postgres/mysql we provide a precompiles plugin, but don’t ship the client libs which has proven to be problematic, as users wonder why it doesn’t work, or because of BC issues on Windows. 

Other SQL plugins such as Oracle or DB2 are only reachable through compiling the source code. Unfortunately we don’t make that easy currently, as these plugins are shipped as part of qtbase, not as a standalone package.

It might make sense to rethink this, and provide those plugins as standalone source packages, that can be easily compiled within creator by our users. That would of probably also require that they live in a repository separate from qtbase (for SQL) or qt3d (in your case).

Cheers,
Lars

>
>Cheers,
>
>Sean
>
>ps Thanks for the Lys tool. Really useful and I use it a lot. :)
>
>>
>> Thanks,
>> Chris Gilbert
>> Knald Technologies, LLC
>>
>> On 10/30/2016 10:11 AM, Thiago Macieira wrote:
>>> On domingo, 30 de outubro de 2016 09:03:59 PDT Sean Harmer wrote:
>>>> I guess this is similar to the database driver plugins.
>>> Right.
>>>
>>> We ship the compiled plugins for both MySQL and PostgreSQL, but not their
>>> libraries, so the plugins can't be loaded unless the user installs the
>>> required client libraries (and in the case of MySQL, since they change
>>> the
>>> soname often, it's a difficult proposal).
>>>
>>> We do not ship compiled plugins for the proprietary databases, like OCI,
>>> Interbase and TDS. People who want one of those can download the
>>> sources and
>>> compile themselves. That's just the plugin, no need to recompile all
>>> of Qt.
>>>
>>> With my OSS hat on, I would say we shouldn't ship even a non-working
>>> binary.
>>> People who want it should download the source for the module and compile
>>> themselves. It is, after all, just a qmake && make.
>>>
>>
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>
>-- 
>Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
>KDAB (UK) Ltd, a KDAB Group company
>Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
>Mobile: +44 (0)7545 140604
>KDAB - Qt Experts
>_______________________________________________
>Development mailing list
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development