On Mon, Feb 16, 2009 at 7:10 AM, grauzone <none@example.net> wrote:
> Jarrett Billingsley wrote:
>>
>> On Sun, Feb 15, 2009 at 9:27 PM, Eldar Insafutdinov <e.insafutdinov@gmail.com> wrote:
>>>>
>>>> The reason why is this file is big is in this bug http://d.puremagic.com/issues/show_bug.cgi?id=282 And I don't thing that placing enums outside the class is a good idea, because enums will be exposed to global namespace unlike original Qt version. I have just checked, if enum A belongs to qt.core.Qt module you can't access it like Qt.A - which means that we have to keep that file big until this bug is fixed.
>>>
>>> Anyway, I tried to place enums outside the classes, and I got:
>>> qt/core/QFile.d(24): Error: enum FileError is forward referenced
>>> qt/core/QFile.d(24): Error: enum FileError is forward referenced
>>> qt/core/QFile.d(24): Error: enum FileError is forward referenced
>>> qt/core/QFile.d(24): Error: enum FileError is forward referenced
>>> qt/core/QFile.d(24): Error: enum FileError is forward referenced
>>> qt/core/QFile.d(24): Error: enum FileError is forward referenced
>>> qt/core/QFile.d(24): Error: enum FileError is forward referenced
>>> qt/core/QFile.d(24): Error: enum FileError is forward referenced
>>>
>>> Circular import is present.
>>
>> You would do well to remove all circular imports.  They make the compiler do stupid things.
>
> I really wonder why Walter doesn't just forbid circular dependencies in the language spec.

Because that's redefining the problem rather than solving it?

Circular dependencies are not always a sign of bad design.  Shoving everything into one module sure is.

Don Wrote:

> Eldar Insafutdinov wrote:
> > Bill Baxter Wrote:
> > 
> >> On Mon, Feb 16, 2009 at 4:38 AM, Eldar Insafutdinov <e.insafutdinov@gmail.com> wrote:
> >>> Bill Baxter Wrote:
> >>>
> >>>> On Mon, Feb 16, 2009 at 4:28 AM, Eldar Insafutdinov <e.insafutdinov@gmail.com> wrote:
> >>>>> Bill Baxter Wrote:
> >>>>>
> >>>>>> On Mon, Feb 16, 2009 at 4:11 AM, Eldar Insafutdinov <e.insafutdinov@gmail.com> wrote:
> >>>>>>> Bill Baxter Wrote:
> >>>>>>>
> >>>>>>>> On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov <e.insafutdinov@gmail.com> wrote:
> >>>>>>>>> Finally we managed to compile qtd for Windows. But at the very last step when compiling example, optlink crashed with a messagebox containing X86 registers content. This seems to be a blocker for qtd working on windows..
> >>>>>>>>>
> >>>>>>>> Was this what you saw?
> >>>>>>>> "Unexpected OPTLINK Termination at EIP=0044C37B"
> >>>>>>>> http://d.puremagic.com/issues/show_bug.cgi?id=424
> >>>>>>>>
> >>>>>>>> Whatever it was, chances are good it's a known bug.  So it would be good to figure out which one it is that you're hitting exactly.
> >>>>>>>>
> >>>>>>>> --bb
> >>>>>>> Yes, it is this issue: "Unexpected OPTLINK Termination at EIP=0041AFFD". And yes, there is 1 quite large file, 14k lines, but because of forward reference and cyclic imports problems we can't split it currently.
> >>>>>> Do you compile it with inlining on?  Not positive about this, but you may be able to cut down on the number of fixups it needs by not using inlining.   Which file is it, anyway?
> >>>>>>
> >>>>>> --bb
> >>>>> it is qt/gui/QPaintDevice.d if you have it. It doesn't work with both inlining and non-inlining.
> >>>> Ok.  Is it some kind of automatically generated file?  I don't see it in the qtd repo.
> >>>>
> >>>> --bb
> >>> yes, all files are automatically generated. If you wish I can upload it(compiled binding with headers) somewhere.
> >> No, that's ok.  I was just curious.  So it sounds like the best hope is to try to find some way to split it up some.  There must be some way it can be broken up, even if that requires turning some private members public.  No?
> >>
> >> --bb
> > 
> > It's in one file because of cyclic imports bug in dmd. The bug with optlink seems to be old, any chance that it's going to be fixed?
> Approximately zero chance. Optlink is entirely written in asm, and AFAIK Walter doesn't want to touch it. There's a much greater chance of the circular imports bug getting fixed -- it has to happen one day.

Ok, so I splitted all big files, circular imports now don't cause troubles. But optlink still crashes. Something else I can try?

Eldar Insafutdinov wrote:
> Finally we managed to compile qtd for Windows. But at the very last
> step when compiling example, optlink crashed with a messagebox
> containing X86 registers content. This seems to be a blocker for qtd
> working on windows..

What you can do is try to obj2asm and dumpobj -p the .obj files, to see if those files are well-formed or not.

On Mon, Feb 16, 2009 at 8:26 PM, Walter Bright <newshound1@digitalmars.com> wrote:
> Eldar Insafutdinov wrote:
>>
>> Finally we managed to compile qtd for Windows. But at the very last step when compiling example, optlink crashed with a messagebox containing X86 registers content. This seems to be a blocker for qtd working on windows..
>
> What you can do is try to obj2asm and dumpobj -p the .obj files, to see if those files are well-formed or not.

I don't know if you realize just how unbelievably unhelpful that advice is for the typical user.

Walter Bright Wrote:

> Eldar Insafutdinov wrote:
> > Finally we managed to compile qtd for Windows. But at the very last step when compiling example, optlink crashed with a messagebox containing X86 registers content. This seems to be a blocker for qtd working on windows..
> 
> What you can do is try to obj2asm and dumpobj -p the .obj files, to see if those files are well-formed or not.

I have never dealed with asm before and besides there are more than 200 files in the project, that would be crucial to check them all.

Jarrett Billingsley wrote:
> On Mon, Feb 16, 2009 at 8:26 PM, Walter Bright
> <newshound1@digitalmars.com> wrote:
>> Eldar Insafutdinov wrote:
>>> Finally we managed to compile qtd for Windows. But at the very last
>>> step when compiling example, optlink crashed with a messagebox
>>> containing X86 registers content. This seems to be a blocker for qtd
>>> working on windows..
>> What you can do is try to obj2asm and dumpobj -p the .obj files, to see if
>> those files are well-formed or not.
> 
> I don't know if you realize just how unbelievably unhelpful that
> advice is for the typical user.

You aren't the typical user <g>. If the obj file is not well-formed, it's a compiler bug, and hence presumably much easier for me to fix.

qtd now works for windows. Here's the binary package http://qtd.googlecode.com/files/qtd-dmd-tango-win32.zip . It is compiled with dmd 1.036 and tango from trunk dated November 2008.

On Sun, Feb 22, 2009 at 5:27 AM, Eldar Insafutdinov <e.insafutdinov@gmail.com> wrote:
> qtd now works for windows. Here's the binary package http://qtd.googlecode.com/files/qtd-dmd-tango-win32.zip . It is compiled with dmd 1.036 and tango from trunk dated November 2008.

Fantastic.  Have you written anywhere how you eventually resolved the linker problems?

--bb