www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Re: QtD 0.1 is out!

reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
ideage Wrote:


 Great stuff!
 
 Expect window's version!
Feb 10 2009
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Wed, Feb 11, 2009 at 6:59 AM, Eldar Insafutdinov
<e.insafutdinov gmail.com> wrote:

 ideage Wrote:


 Great stuff!

 Expect window's version!






wrapper with C++ object files produced by mingw - it didnt work and I was t=
old 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 suppo=
rt exception handling). So the situation is suspended, although I am trying=
 to build it with ldc now.


My usual approach is to use mingw to build a dll out of the needed
functionality.  If you can make the C++ part a DLL then a D program
can use it just fine.

--bb
Feb 10 2009
parent Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Bill Baxter Wrote:


 On Wed, Feb 11, 2009 at 6:59 AM, Eldar Insafutdinov
 <e.insafutdinov gmail.com> wrote:

 ideage Wrote:


 Great stuff!

 Expect window's version!






 
 My usual approach is to use mingw to build a dll out of the needed
 functionality.  If you can make the C++ part a DLL then a D program
 can use it just fine.
 
 --bb



Thanks, but could you please clarify something for me: as well as D part, C++
part is calling extern "C" functions defined in D part of the binding. will
this work with dll? And also currently it doesn't use dynamic loading - it's
just plain extern (C) function definitions on both sides, is this an issue?
Feb 10 2009
prev sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 11 Feb 2009 00:59:28 +0300, Eldar Insafutdinov
<e.insafutdinov gmail.com> wrote:


 ideage Wrote:


 Great stuff!

 Expect window's version!



 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.
Feb 10 2009
next sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
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!



 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..
Feb 11 2009
parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
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!



 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).
Feb 11 2009
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
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!
 



 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.
 



 DMD on Windows.
 



 make is not compatible with the one that comes with dmc? I will
 probably run into a big problem..
 



 compile Qt or not.  I would think it would, though.
 
 --bb
 



 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
Feb 11 2009
next sibling parent John Reimer <terminal.node gmail.com> writes:
 I recommend the ddl route if you can make it work.  




Sorry, not "ddl"... meant to say dll.


:P
Feb 11 2009
prev sibling parent reply Don <nospam nospam.com> writes:
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!



 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.



 DMD on Windows.



 make is not compatible with the one that comes with dmc? I will
 probably run into a big problem..



 compile Qt or not.  I would think it would, though.

 --bb



 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.
Feb 12 2009
next sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
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!



 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.



 DMD on Windows.



 make is not compatible with the one that comes with dmc? I will
 probably run into a big problem..



 compile Qt or not.  I would think it would, though.

 --bb



 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.
Feb 12 2009
next sibling parent Don <nospam nospam.com> writes:
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!



 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.



 DMD on Windows.



 make is not compatible with the one that comes with dmc? I will
 probably run into a big problem..



 compile Qt or not.  I would think it would, though.

 --bb



 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



 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.
Feb 12 2009
prev sibling parent naryl <cy ngs.ru> writes:
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?
Feb 12 2009
prev sibling parent reply naryl <cy ngs.ru> writes:
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. :)
Feb 12 2009
next sibling parent reply Don <nospam nospam.com> writes:
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.
Feb 12 2009
next sibling parent "Nick Sabalausky" <a a.a> writes:
"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 ;-)
Feb 12 2009
prev sibling parent Arnold S. <governator california.gov> writes:
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
Feb 12 2009
prev sibling parent renoX <renosky free.fr> writes:
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
Feb 16 2009
prev sibling parent Daniel de Kok <me danieldk.org> writes:
On Tue, Feb 17, 2009 at 7:06 AM, renoX <renosky free.fr> wrote:

 naryl a =E9crit :

 Don Wrote:

 Well, since Qt is going to use the lunatic# LGPL license, you have to u=










 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 th=







 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 chang=




 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
Feb 17 2009
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
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!



 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
Feb 11 2009