[Development] Distributing 3rd party closed source libs

Donald Carr sirspudd at gmail.com
Wed Nov 2 13:31:47 CET 2016


> Is it really too difficult to download the qt3d source tarball, cd
somewhere,
> type qmake && make?

It does make this kind of functionality hard to test for people outside of
the hardened Qt community. Well documented manual processes are always an
acceptable baseline, but they introduce a barrier to entry which is why I
am glad this discussion is occurring.

> $$[QT_INSTALL_DATA]/plugins would actually put the sources right next to
> the compiled plugins in a default install.

sounds very transparent and would allow someone to see every proprietary
plugin available to them, but only for users who build their own Qt, and
only once they stub their toes on this practice.

To a certain extent it is a pity there is no tool similar to the Qt SDK
installer client for Qt itself, which would allow you to at least centrally
pull down modules requiring manual intervention. Deploying modules which
need to be manually compiled in a massive larger tarball completely
occludes their existence to all but the familiar. Compare a list of 6 or
available plugins which require further requirements and compilation to a
subdir somewhere in the complete qt versioned source package. The argument
about going outside of distro package management is moot since we are
talking about proprietary license restricted plugins and every other
development platform on earth now steps on the toes of the local distro
package manager in the name of convenience.

> 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.

The discrete source package (created when the qt release tarball is
created?) sounds like a good start to centralizing these for localized
consideration.

//* Looking forward to qt-plugins-dirty packages in the package manager :p

If I were to use this plugin itself, the first thing I would currently do
is create an aur recipe for it (doing exactly what Thiago suggested) under
Arch Linux, but this is clearly a suboptimal reality since it does
not improve/solve visibility, hits one narrow audience and still is a hacky
extension to the package manager.) *//


On Tue, Nov 1, 2016 at 3:45 PM Thiago Macieira <thiago.macieira at intel.com>
wrote:

> On segunda-feira, 31 de outubro de 2016 13:06:04 PDT Sean Harmer wrote:
> > > 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).
> > I like that idea. We could add those repos as source only options to the
> > Qt SDK installer to make it easy for end user developers.
> >
> > To this end, could somebody create us a qt3d-plugins git repo and gerrit
> > project please?
>
> Is it really too difficult to download the qt3d source tarball, cd
> somewhere,
> type qmake && make?
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20161102/52f22eae/attachment.html>


More information about the Development mailing list