Re: version specific enum members

2009-10-30 Thread Phil Deets
On Fri, 30 Oct 2009 06:38:44 -0500, Ary Borenszweig   
wrote:



Phil Deets wrote:
On Thu, 29 Oct 2009 18:28:12 -0500, Ary Borenszweig  
 wrote:



Ellery Newcomer wrote:

 Unfortunately, that's going to be about the best you can do, unless
you're willing to play with string mixins and their ilk.


Or unless you create an enhancement request. That seems a very valid  
one.

 Done (on the main D list).


I meant a bugzilla enhancement, otherwise it'll get lost in the  
newsgroups.


Well, I wanted to gauge support for the idea. It turns out I found a  
string mixin workaround that works; so it isn't critical for me now.


Re: Mixins output handling

2009-10-30 Thread Trass3r

Zarathustra schrieb:

Is there a some compiler switch to produce mixins output.

I mean [d_file_with_mixins] -> [d_file_without_mixins].


No, Descent has such a feature though.


Mixins output handling

2009-10-30 Thread Zarathustra
Is there a some compiler switch to produce mixins output.

I mean [d_file_with_mixins] -> [d_file_without_mixins].


Re: Linking problem with QtD

2009-10-30 Thread Eldar Insafutdinov
Qian Xu Wrote:

> Eldar Insafutdinov wrote:
> > 
> > All Qt versions keep forward binary compatibility and a full compatibility
> > within a major version, 4.5.3 contains only bug fixes compared to 4.5.2.
> > Version from code.google.com is a way to old, so I would not even
> > consider it. Have you tried to turn on BUILD_EXAMPLES option in cmake? It
> > will build all examples bundled with qtd.
> 
> The problem has been solve.
> 
> The linker "ld" searches first in "/usr/lib" (Qt 4.4.3) and then
> my "/my-qt-sdk/lib", even when the path "/usr/lib" is not specified. 
> 
> I checked the man page of "ld". There is an argument "-rpath-link". If it is
> not specified, the "/usr/lib" will be assumed.
> 
> So my problem is solve. Thanks for you all. Have a nice day.

You are welcome. I'm glad you solved the problem. Yes, I should've guessed an 
issue, since it was missing symbols from Qt 4.5, on which QtD is based on. And 
it worked with version from google-code, because it was using Qt 4.4.


Re: Linking problem with QtD

2009-10-30 Thread Qian Xu
Eldar Insafutdinov wrote:
> 
> All Qt versions keep forward binary compatibility and a full compatibility
> within a major version, 4.5.3 contains only bug fixes compared to 4.5.2.
> Version from code.google.com is a way to old, so I would not even
> consider it. Have you tried to turn on BUILD_EXAMPLES option in cmake? It
> will build all examples bundled with qtd.

The problem has been solve.

The linker "ld" searches first in "/usr/lib" (Qt 4.4.3) and then
my "/my-qt-sdk/lib", even when the path "/usr/lib" is not specified. 

I checked the man page of "ld". There is an argument "-rpath-link". If it is
not specified, the "/usr/lib" will be assumed.

So my problem is solve. Thanks for you all. Have a nice day.


Re: version specific enum members

2009-10-30 Thread Ary Borenszweig

Phil Deets wrote:
On Thu, 29 Oct 2009 18:28:12 -0500, Ary Borenszweig 
 wrote:



Ellery Newcomer wrote:

Phil Deets wrote:

Hi, is there a way to add members to an enum based on conditional
compilation symbols. I tried

enum Tag {
   A, B,
   version (symbol) {
  C, D,
   }
   E,
}

but it doesn't work. I know I could do

version (symbol) {
   enum Tag { A, B, C, D, E }
} else {
   enum Tag { A, B, E }
}

but I don't want to do that since in my case, there can be quite a few
elements outside of the version, and I don't want to repeat them all.



 Unfortunately, that's going to be about the best you can do, unless
you're willing to play with string mixins and their ilk.


Or unless you create an enhancement request. That seems a very valid one.


Done (on the main D list).


I meant a bugzilla enhancement, otherwise it'll get lost in the newsgroups.


Re: Linking problem with QtD

2009-10-30 Thread Eldar Insafutdinov
Qian Xu Wrote:

> Eldar Insafutdinov wrote:
> > 
> > I saw you made the reference to this link
> > (http://www.dsource.org/projects/qtd/wiki/MacCaseStudy which contains this
> > command line option, but still I don't understand why you get undefined
> > symbols like QPrintDialog::options() const which belongs to libQtGui.
> 
> Because the demo project uses QApplication and QMainWindow, which belong to
> libQtGui.

Yes it does. Can you post the exact command line that you use when building an 
example?


Re: Linking problem with QtD

2009-10-30 Thread Qian Xu
Eldar Insafutdinov wrote:
> 
> I saw you made the reference to this link
> (http://www.dsource.org/projects/qtd/wiki/MacCaseStudy which contains this
> command line option, but still I don't understand why you get undefined
> symbols like QPrintDialog::options() const which belongs to libQtGui.

Because the demo project uses QApplication and QMainWindow, which belong to
libQtGui.