Don Wrote:

> John Reimer wrote:
> > Hello Eldar,
> > 
> >> Bill Baxter Wrote:
> >>
> >>> On Wed, Feb 11, 2009 at 8:10 PM, Eldar Insafutdinov <e.insafutdinov@gmail.com> wrote:
> >>>
> >>>> Denis Koroskin Wrote:
> >>>>
> >>>>> On Wed, 11 Feb 2009 00:59:28 +0300, Eldar Insafutdinov <e.insafutdinov@gmail.com> wrote:
> >>>>>
> >>>>>> ideage Wrote:
> >>>>>>
> >>>>>>> Great stuff!
> >>>>>>>
> >>>>>>> Expect window's version!
> >>>>>>>
> >>>>>> So after some time trying to build qtd windows packages I realized that there are huge issues. I tried first dmd and since I have to link D part of wrapper with C++ object files produced by mingw - it didnt work and I was told that it's because mingw and dmd have different object file formats. So 2 options left are gdc(which is kinda outdated) and ldc(which doesn't support exception handling). So the situation is suspended, although I am trying to build it with ldc now.
> >>>>>>
> >>>>> You can try building Qt with DMC. It works quite will in pair with DMD on Windows.
> >>>>>
> >>>> And will dmc be able to compile Qt? And also as much as I undestdood make is not compatible with the one that comes with dmc? I will probably run into a big problem..
> >>>>
> >>> You could use mingw's GNU make with CC=dmc.  But I dunno if dmc will compile Qt or not.  I would think it would, though.
> >>>
> >>> --bb
> >>>
> >> Actually I decided to make a dll. It is possible to do it and will be more robust solution. Qt is not tested to be compiled with dmc by trolltech(mingw, msvc and icc are guaranteed).
> >>
> > 
> > 
> > A dll is probably your best option, if you can make it work with the C++ code(?).  I would have thought you needed a C interface, though.
> > 
> > dmc is rarely supported by the majority of open-source projects out there, so you end up having to fix a lot of makefiles and a lot of code.  It is especially difficult getting C++ code working with such projects because many of these will use macro definitions to enable/disable certain vendor compiler features.  Also you will run into C++ implementation differences that make dmc choke.
> > 
> > 
> > On several occasions where I've tried to use dmc for the same reason, and I've come to the conclusion that dmc support is a whole project in itself. It's a huge waste of time if all you want is to interface with a library. I recommend the ddl route if you can make it work.  Most others have done the same.
> > 
> > 
> > Incindentally, if you are curious why projects like Derelict and other bindings (using dynamic loading) are so oft used in the D community, this is pretty much the reason.
> > 
> > 
> > -JJR
> 
> Well, since Qt is going to use the lunatic# LGPL license, you have to use a DLL anyway for commercial use.
> 
> # lunatic because of the prohibition against static linking. I cannot understand why anyone would use such an absolutely moronic license.

I'm thinking on putting only C++ part of binding to a dll, while statically link D part. With Qt 4.5 out under lgpl we can make QtD under BSD, so this will work.

Eldar Insafutdinov wrote:
> Don Wrote:
> 
>> John Reimer wrote:
>>> Hello Eldar,
>>>
>>>> Bill Baxter Wrote:
>>>>
>>>>> On Wed, Feb 11, 2009 at 8:10 PM, Eldar Insafutdinov
>>>>> <e.insafutdinov@gmail.com> wrote:
>>>>>
>>>>>> Denis Koroskin Wrote:
>>>>>>
>>>>>>> On Wed, 11 Feb 2009 00:59:28 +0300, Eldar Insafutdinov
>>>>>>> <e.insafutdinov@gmail.com> wrote:
>>>>>>>
>>>>>>>> ideage Wrote:
>>>>>>>>
>>>>>>>>> Great stuff!
>>>>>>>>>
>>>>>>>>> Expect window's version!
>>>>>>>>>
>>>>>>>> So after some time trying to build qtd windows packages I realized
>>>>>>>> that there are huge issues. I tried first dmd and since I have to
>>>>>>>> link D part of wrapper with C++ object files produced by mingw -
>>>>>>>> it didnt work and I was told that it's because mingw and dmd have
>>>>>>>> different object file formats. So 2 options left are gdc(which is
>>>>>>>> kinda outdated) and ldc(which doesn't support exception handling).
>>>>>>>> So the situation is suspended, although I am trying to build it
>>>>>>>> with ldc now.
>>>>>>>>
>>>>>>> You can try building Qt with DMC. It works quite will in pair with
>>>>>>> DMD on Windows.
>>>>>>>
>>>>>> And will dmc be able to compile Qt? And also as much as I undestdood
>>>>>> make is not compatible with the one that comes with dmc? I will
>>>>>> probably run into a big problem..
>>>>>>
>>>>> You could use mingw's GNU make with CC=dmc.  But I dunno if dmc will
>>>>> compile Qt or not.  I would think it would, though.
>>>>>
>>>>> --bb
>>>>>
>>>> Actually I decided to make a dll. It is possible to do it and will be
>>>> more robust solution. Qt is not tested to be compiled with dmc by
>>>> trolltech(mingw, msvc and icc are guaranteed).
>>>>
>>>
>>> A dll is probably your best option, if you can make it work with the C++ code(?).  I would have thought you needed a C interface, though. 
>>>
>>> dmc is rarely supported by the majority of open-source projects out there, so you end up having to fix a lot of makefiles and a lot of code.  It is especially difficult getting C++ code working with such projects because many of these will use macro definitions to enable/disable certain vendor compiler features.  Also you will run into C++ implementation differences that make dmc choke.
>>>
>>>
>>> On several occasions where I've tried to use dmc for the same reason, and I've come to the conclusion that dmc support is a whole project in itself. It's a huge waste of time if all you want is to interface with a library. I recommend the ddl route if you can make it work.  Most others have done the same.
>>>
>>>
>>> Incindentally, if you are curious why projects like Derelict and other bindings (using dynamic loading) are so oft used in the D community, this is pretty much the reason.
>>>
>>>
>>> -JJR
>> Well, since Qt is going to use the lunatic# LGPL license, you have to use a DLL anyway for commercial use.
>>
>> # lunatic because of the prohibition against static linking. I cannot understand why anyone would use such an absolutely moronic license.
> 
> I'm thinking on putting only C++ part of binding to a dll, while statically link D part. With Qt 4.5 out under lgpl we can make QtD under BSD, so this will work.
Cool!

Don Wrote:
> Well, since Qt is going to use the lunatic# LGPL license, you have to use a DLL anyway for commercial use.
> 
> # lunatic because of the prohibition against static linking. I cannot understand why anyone would use such an absolutely moronic license.

LGPL doesn't explicitly prohibits static linking. It serves to ensure that the modified library can be replaced by other version at any time. And there's a good reason for that.

Obviously you can't replace a library with other version if it's statically linked. But nothing prohibits from distributing a product in object files. :)

Eldar Insafutdinov Wrote:
> I'm thinking on putting only C++ part of binding to a dll, while statically link D part. With Qt 4.5 out under lgpl we can make QtD under BSD, so this will work.

You mean the Revised BSD License I presume?

naryl wrote:
> Don Wrote:
>> Well, since Qt is going to use the lunatic# LGPL license, you have to use a DLL anyway for commercial use.
>>
>> # lunatic because of the prohibition against static linking. I cannot understand why anyone would use such an absolutely moronic license.
> 
> LGPL doesn't explicitly prohibits static linking. It serves to ensure that the modified library can be replaced by other version at any time. And there's a good reason for that.

Yes. But does ANYONE ever do that? It's an invitation to DLL hell.

> Obviously you can't replace a library with other version if it's statically linked. But nothing prohibits from distributing a product in object files. :)

Exactly. That's why it's the lunatic license.
The LGPL inconveniences everyone in order to preserve a freedom which benefits NOBODY. It feels to me like giving you a free car PROVIDED that you ensure that there is a coffee cup glued to the top of it at all times.

I'm strongly in favour of the GPL (especially for apps), but the LGPL is pure lunacy.

"Don" <nospam@nospam.com> wrote in message news:gn1saj$14uo$1@digitalmars.com...
> It feels to me like giving you a free car PROVIDED that you ensure that there is a coffee cup glued to the top of it at all times.
>

I'd go for that ;-)

Don Wrote:

> naryl wrote:
> > Don Wrote:
> > Obviously you can't replace a library with other version if it's statically linked. But nothing prohibits from distributing a product in object files. :)
> 
> Exactly. That's why it's the lunatic license.
> The LGPL inconveniences everyone in order to preserve a freedom which
> benefits NOBODY. It feels to me like giving you a free car PROVIDED that
> you ensure that there is a coffee cup glued to the top of it at all times.

Awesome.  It'll be law by next Tuesday.  Thanks for the idea.

  -AS

naryl a écrit :
> Don Wrote:
>> Well, since Qt is going to use the lunatic# LGPL license, you have to use a DLL anyway for commercial use.
>>
>> # lunatic because of the prohibition against static linking. I cannot understand why anyone would use such an absolutely moronic license.
> 
> LGPL doesn't explicitly prohibits static linking. It serves to ensure that the modified library can be replaced by other version at any time. And there's a good reason for that.
> 
> Obviously you can't replace a library with other version if it's statically linked. But nothing prohibits from distributing a product in object files. :)

I disagree: the LGPL is probably the most 'derived' license: because developers don't like the stupid restriction on static linking they change it..

Too bad as it creates a lot of different LGPL-like license.

That said, I know for sure that the LGPLv2 prevents static linking I don't know about the LGPLv3 though.

BR,
renoX

On Tue, Feb 17, 2009 at 7:06 AM, renoX <renosky@free.fr> wrote:
> naryl a écrit :
>>
>> Don Wrote:
>>>
>>> Well, since Qt is going to use the lunatic# LGPL license, you have to use a DLL anyway for commercial use.
>>>
>>> # lunatic because of the prohibition against static linking. I cannot understand why anyone would use such an absolutely moronic license.
>>
>> LGPL doesn't explicitly prohibits static linking. It serves to ensure that the modified library can be replaced by other version at any time. And there's a good reason for that.
>>
>> Obviously you can't replace a library with other version if it's statically linked. But nothing prohibits from distributing a product in object files. :)
>
> I disagree: the LGPL is probably the most 'derived' license: because developers don't like the stupid restriction on static linking they change it..

Well, there's another reason: the LPGL (at least version 2.1) is not exactly clear on the status of templates. Does instantiating a template create a derived work or not? This is also the reason why Qt Software/Nokia is currently still working on their modification of the GPL.

The non-static restriction is probably built in for guaranteeing 'user freedom' with respect to the LGPLed code, but in practice it's a PITA for the user because it requires you to carry around a bunch of DLLs.

Oh well :). All hail the Apache 2.0 license ;).

Take care,
Daniel