[Development] QtSC: Scene Graph discussion

Laszlo Papp lpapp at kde.org
Thu Aug 1 20:38:12 CEST 2013


3


On Thu, Aug 1, 2013 at 7:25 PM, Hausmann Simon <Simon.Hausmann at digia.com>wrote:

>  Interesting point.
>
>  In your environment where you are already building your custom version
> of Qt, how many processes do you expect to be running simultaneously that
> are also using QtSceneGraph (without QtQml/QtQuick)?
>
>
>  Simon
>
>     *Fra: *Laszlo Papp
> *Sendt: *19:30 torsdag 1. august 2013
> *Til: *Thiago Macieira
> *Kopi: *development at qt-project.org
> *Emne: *Re: [Development] QtSC: Scene Graph discussion
>
>  On Thu, Aug 1, 2013 at 6:22 PM, Thiago Macieira <
> thiago.macieira at intel.com> wrote:
>
>>  On quinta-feira, 1 de agosto de 2013 17:57:03, Laszlo Papp wrote:
>> > On Thu, Aug 1, 2013 at 5:52 PM, Hausmann Simon
>> <Simon.Hausmann at digia.com>wrote:
>> > >  What is the advantage of this approach over static linkage?
>> >
>> > 1) Not linking into more applications running.
>> >
>> > 2) It is also safer for the LGPLv2 license without an exception for
>> static
>> > linking into commercial code.
>> >
>> > 3) shared library is more widely used so it is more natural for me.
>>
>>  Advantages 1 and 3 make no difference because you'll be building it on
>> your
>> own. There will be no sharing of code at runtime. In fact, deploying a
>> shared
>> library may also make packaging your application more (not less)
>> difficult.
>>
>
>  Err... 1) does not make a difference on embedded with a small NOR/NAND
> flash? Perhaps, you are thinking about desktop? As far as I can tell, it is
> such a big difference that we would need reject Qt if we only had the
> static linking option.
>
>  I still feel a lot more comfortable with 3) than without. So, yes, 3) is
> not necessarily a blocker, just a nice convenience, but 1)-2) are blockers
> against using Qt in that way.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130801/0d82e19d/attachment.html>


More information about the Development mailing list