www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - D for Xcode 1.0

reply Michel Fortin <michel.fortin michelf.com> writes:
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/
Nov 20 2007
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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)
Nov 21 2007
prev sibling parent reply =?ISO-8859-1?Q?Pablo_Ripoll=e9s?= <in-call gmx.net> writes:
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!
Nov 22 2007
parent reply Michel Fortin <michel.fortin michelf.com> writes:
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/
Nov 22 2007
parent Pablo Ripolles <in-call gmx.net> writes:
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/

Nov 23 2007