On 4/2/10 03:35, Michel Fortin wrote:
On 2010-04-01 15:24:59 -0400, Jacob Carlborg <d...@me.com> said:
I've download the new version of your plugin and have tested it and
have few comments.
The first thing I noticed when I compiled a project was that it tries
to pass the '-noboundscheck' flag to DMD, which it doesn't support.
Yes it does, but only for D2. It should not do that by default though...
I'll look at it. Ideally this option wouldn't be available for D1, but
the way the default compiler version is chosen makes it difficult to
know which one is used.
I had no idea that DMD2 supported the -noboundscheck flag.
I also noted that now the plugin overwrites/removes the GDC support.
It would be nice if both could be supported.
It's not really gone. You can add a build rule in each target specifying
GDC as the compiler for D source files. I would like to have a better
solution, but right now I don't.
Ideally, there would be a build setting for choosing the default
compiler, just like Xcode let you choose between GCC 4.0, GCC 4.2,
GCC-LLVM and Clang. But I haven't been able to make something similar.
If you ever implement this there could be separate options for DMD1 and
DMD2.
Have you ever investigated if it would be possible create a plugin for
Interface Builder that would add D support? I've been thinking of two
ways this might be done.
I've found this blog post which I think is quite interesting:
http://cocoawithlove.com/2009/02/interprocess-communication-snooping.html
. I was thinking if the method described there could be used to add D
support to Interface Builder. I was thinking of implementing a class
that generates temporary Objective-C header files out of D files,
implementing the methods described in the post and responding with the
temporary Objective-C files. I've tried to implement a kind of dummy
class which responds to the methods but Interface Builder didn't like
them for some reason.
The other idea I was thinking of was to create an actual plugin for
Interface Builder containing a D parser that does the same as
Interface Builder does but for D files.
I'm not sure I understand clearly what you mean by 'D support for IB',
but here's what I can say:
Interface Builder generates some sort of serialization of Objective-C
objects. You need the D/Objective-C bridge to load Nib files
instantiating D classes (but it works!). If you want Interface Builder
to recognize D files with the IBOutlet and IBAction templates found in
the D/Objective-C bridge, then making a parser plugin for IB (your
second option) would make most sense.
I was referring to Interface Builder recognizing D files with the
IBOutlet and IBAction templates. I was thinking that since you already
have an XCode plugin and if you could access the mentioned methods it
could be easier using the first option. But as a long term solution the
second option would be the preferred one.
But I'm not there yet. making the bridge work on Snow Leopard has a
higher priority right now (even though I'm not really working on that
currently).
Great work by the way with the plugin, I specially like that D files
are correctly recognized now.
Thanks for your comments.
