On Thu, 03 Sep 2009 19:45:44 -0400, Robert Jacques <sandf...@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.
