One month ago, I released my D plugin for Xcode. I released it under a beta cover since I was pretty sure there was still some crashing bugs in the code (and I was right).

Today, I'm confident enough to release a first non-beta version. It includes some fixes and improvements. D fox Xcode is also more polished, showing proper D icons at the right places and automatically handling D files double-clicked from the Finder.

More importantly it becomes compatible with the Xcode 2.5 which was unlashed this month and which is available for Mac OS X 10.5 Leopard in addition to 10.4 Tiger. I haven't tested the plugin on Leopard as I do not have Leopard at hand, but I'm confident it'll work (using Xcode 2.5, not with Xcode 3). Since D for Xcode depends on GDC to be useful, it'll also be interesting to hear about how well GDC runs on Leopard.

I want to thank specially Anders F Björklund for his comments, insights, and his help in testing the plugin.

D fox Xcode is made available here under the GNU General Public License version 2 or later:
<http://www.michelf.com/projects/d-for-xcode/>

Changes since D for Xcode 1.0b1:

*  New output parser with support for correctly reporting warnings
  (note that warnings are deactivated by default).

*  Removed the Treat Warnings as Error option. Rationale: GDC
  automatically treat warnings as error when they're enabled so this
  option had no effect.

*  Module Search Paths now include "/usr/include/d" by default, because
  that's where most libraries are expected to install their interface
  files. You can remove it from the project or target settings.

*  Version Identifiers no longer contain "Posix darwin" by default. You
  can add them back in the project or target settings.
  (This may be needed for Tango.)

*  Inline Functions is now an option in the Code Generation category.
  [-finline-functions]

*  Fixed a typo which made Generate Debug Symbols off by default; it is
  now on by default.

*  Added a Instruction Scheduling option in the Code Generation section,
  allowing generated code to be tuned for G3, G4, or G5 processors.
  [-mtune=<cpu>]

*  Change how the linker is configured so that it now can use the
  system's libgphobos.a even when using a SDK. As a side effect, GCC
  is now used as a linker instead of GDC (not that this change much
  things).

*  Fixed two infinite loops in the code parser which would stall
  and/or crash Xcode, and preemptively reviewed the code and removed
  a few other potential infinite loops.

*  Added some icons to the user interface for displaying D files in
  lists and for build settings.

*  Added a launcher application (hidden inside the plugin bundle) which
  gives an appropriate icon to .d and .di files in the Finder and
  redirects opened files to Xcode. On Mac OS X 10.5 Leopard, the
  launcher attempt to open D files using Xcode 2.5 (if installed at
  its default location), as the plugin doesn't work with Xcode 3.

Known Issues:

*  Compiling with a SDK under Xcode 2.4.1 generates an innocuous missing
  directory warning when linking. You can add an empty directory at the
  specified path in the SDK to remove that warning, or you can upgrade
  to Xcode 2.5 which seem to no longer exhibit this behaviour.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Michel Fortin wrote:

> Today, I'm confident enough to release a first non-beta version. It includes some fixes and improvements. D fox Xcode is also more polished, showing proper D icons at the right places and automatically handling D files double-clicked from the Finder.

Excellent work!

> More importantly it becomes compatible with the Xcode 2.5 which was unlashed this month and which is available for Mac OS X 10.5 Leopard in addition to 10.4 Tiger. I haven't tested the plugin on Leopard as I do not have Leopard at hand, but I'm confident it'll work (using Xcode 2.5, not with Xcode 3). Since D for Xcode depends on GDC to be useful, it'll also be interesting to hear about how well GDC runs on Leopard.

It is possible to use the GDC 0.24 version (for Tiger) with Leopard,
provided that the the GCC support files are added from the tarball
that were left out in the gdcmac PKG. (this is because it is looking
for the files for "darwin8", but can only find the new "darwin9" now)

Installing those in /usr/lib/gcc (maybe some in /usr/libexec/gcc)
makes it just fine to use GDC from Leopard as well (with Xcode 2.5).
I think you might even be able to install the GDC files under the
Xcode 2.5 install location (/Xcode2.5), but I haven't tried it yet.

> I want to thank specially Anders F Björklund for his comments, insights, and his help in testing the plugin.

You are welcome!

--anders


PS.
On a totally unrelated note, another Code::Blocks Mac build was posted:
http://prdownload.berlios.de/codeblocks/CB_20071115_rev4639_mac286.zip
It's not as nice as Xcode, but freely available under the GPL license.
(it uses wxWidgets, and is available for Windows and GNU/Linux as well)

Michel Fortin Wrote:

> One month ago, I released my D plugin for Xcode. I released it under a beta cover since I was pretty sure there was still some crashing bugs in the code (and I was right).
> 
> Today, I'm confident enough to release a first non-beta version. It includes some fixes and improvements. D fox Xcode is also more polished, showing proper D icons at the right places and automatically handling D files double-clicked from the Finder.
> 

Hello!

I've observed that after installing the plug-in in the specified folder (which in my case I have to create it), the icon doesn't get automatically registered.  Besides, double-clicking in the default white icon doesn't launch any Xcode but the typical dialog offering which application to use.  Once I've chosen Xcode the double-clicking works and but the icon remains in its default unknown white state.  The Xcode gets launched and the editor window showing the source has no [d] icon on its title bar.  On a side note, for if it helps, it can be observed that right clicking on a d file and selecting "Open With" shows Xcode duplicated:  "Xcode.app" but also "Xcode.app (default)".  This is something which doesn't occur on c files for example.  Is this the expected behaviour?

Thanks!

On 2007-11-22 06:48:24 -0500, Pablo Ripoll	s <in-call@gmx.net> said:

> Hello!
> 
> I've observed that after installing the plug-in in the specified folder (which in my case I have to create it), the icon doesn't get automatically registered.  Besides, double-clicking in the default white icon doesn't launch any Xcode but the typical dialog offering which application to use.  Once I've chosen Xcode the double-clicking works and but the icon remains in its default unknown white state.  The Xcode gets launched and the editor window showing the source has no [d] icon on its title bar.

I suggest you duplicate the plugin in the Finder so the system take notice of the hidden launcher application inside. Perhaps after that you'll have to use the get info window on a D file to set the associated application to the D for Xcode Launcher since you've manually attached d documents to Xcode. I think will this you'll get the icons. (You may need to reopen your user session to see the icon change in the Finder.)

I'll have to check for a way to make the launcher application registeration process more seamless for when the system fail to see notice application by its own. Thank you for reminding me of this issue.


> On a side note, for if it helps, it can be observed that right clicking on a d file and selecting "Open With" shows Xcode duplicated:  "Xcode.app" but also "Xcode.app (default)".  This is something which doesn't occur on c files for example.  Is this the expected behaviour?

I don't think this is related.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Michel Fortin Wrote:

> On 2007-11-22 06:48:24 -0500, Pablo Ripoll	s <in-call@gmx.net> said:
> 
> > Hello!
> > 
> > I've observed that after installing the plug-in in the specified folder (which in my case I have to create it), the icon doesn't get automatically registered.  Besides, double-clicking in the default white icon doesn't launch any Xcode but the typical dialog offering which application to use.  Once I've chosen Xcode the double-clicking works and but the icon remains in its default unknown white state.  The Xcode gets launched and the editor window showing the source has no [d] icon on its title bar.
> 
> I suggest you duplicate the plugin in the Finder so the system take notice of the hidden launcher application inside. Perhaps after that you'll have to use the get info window on a D file to set the associated application to the D for Xcode Launcher since you've manually attached d documents to Xcode. I think will this you'll get the icons. (You may need to reopen your user session to see the icon change in the Finder.)
> 

Perfect!!! amazing! thanks a lot!

Indeed I didn't copy the plug-in to the /Library/... destination directory using the Finder.  Mostly when I work as administrator I do it using sudo in the Terminal.  In this case I copied the plug-in this way too.  It might be interesting to mention it on the web installation notes.

> I'll have to check for a way to make the launcher application registeration process more seamless for when the system fail to see notice application by its own. Thank you for reminding me of this issue.
> 

Please! you'r welcome!

> 
> > On a side note, for if it helps, it can be observed that right clicking on a d file and selecting "Open With" shows Xcode duplicated: "Xcode.app" but also "Xcode.app (default)".  This is something which doesn't occur on c files for example.  Is this the expected behaviour?
> 
> I don't think this is related.
> 
> -- 
> Michel Fortin
> michel.fortin@michelf.com
> http://michelf.com/
>