dmd 1.047 and 2.032 releases

[Robert Jacques]

On Thu, 03 Sep 2009 19:45:44 -0400, Robert Jacques <sandford at jhu.edu>  
wrote:

> Thanks for yet another great release, but.. has anyone else gotten DFL  
> to compile? (The latest svn of DFL worked fine in 2.031)
>
> I've been trying to get it up and running but I've been seeing really  
> weird errors. It appears in several cases that various import statements  
> are not being imported. For example:
>
>      import dfl.menu;
>      import dfl.form;
>
> Seems to import the menu classes, but not the form classes. And
>
>      import dfl.form;
>      import dfl.menu;
>
> does the opposite.
>
> I tried tracing the issue down (from control.d -> menu.d ->  
> application.d -> form.d, testing using dfl.internal.winapi) and it  
> looked like I found a single line of code in form.d
>
> version(NO_MDI) {} else {
> // commented out source
> }
>
> in which a public import dfl.internal.winapi worked above and didn't  
> work below. But, when I tried to make a simple test case, everything  
> worked. And then when I came back to full source, that test worked too,  
> as did form (But that was only because I had publicly imported it from  
> application.d & application from menu.d)

With some more hacking, I've gotten it to compile. It appears to be  
something to do in how cyclic (+ private duplicates?) imports are handled.  
I made everything public and then commented out some of the redundant  
imports. The strange thing is that I didn't have to remove all cycles or  
all redundant imports to get it compiling. I did get a less hacked up  
version running (package imports + removed redundancies), but I had to  
turn off drag and drop support in order to get it to compile and swapping  
around certain import statements still causes errors.