www.digitalmars.com         C & C++   DMDScript  

D.gnu - XCode 2.4 and gdc

reply Charles Kerr<punt1959 msn.com> writes:
Does anyone have a a set of recent instructions and files to get D
working on Mac OS X 10.4 and XCode 2.4?
I downloaded gdc .19 for the ppc (I have a G5 iMac) but not sure where
to put the folder (if the plugins require a specific location).
All the xcode instructions seem to be very dated (1.5), so not sure the
what files to get and where to put them. 
Any/All help would be appreciated.
-- 
Sep 29 2006
parent reply Fredrik Olsson <peylow gmail.com> writes:
Charles Kerr skrev:
 
 Does anyone have a a set of recent instructions and files to get D
 working on Mac OS X 10.4 and XCode 2.4?
 I downloaded gdc .19 for the ppc (I have a G5 iMac) but not sure where
 to put the folder (if the plugins require a specific location).
 All the xcode instructions seem to be very dated (1.5), so not sure the
 what files to get and where to put them. 
 Any/All help would be appreciated.
The support files for Xcode are hidden in: /Library/Application Support/Apple/Developer Tools/ A quite long but logical path. I suggest that after installing the usual D support you also get this: http://peylow.no-ip.org/DTool.zip It is a project template for a tool application in D. It solves a few problems present in Xcode 2.2 and later. Apple decided to change some of the syntax... breaking the earlier templates. // Fredrik Olsson
Oct 02 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Fredrik Olsson wrote:

 The support files for Xcode are hidden in:
 /Library/Application Support/Apple/Developer Tools/
 A quite long but logical path.
Paths with spaces in them suck eggs, logical or not. /Library/Application\ Support/Apple/Developer\ Tools
 It is a project template for a tool application in D. It solves a few 
 problems present in Xcode 2.2 and later. Apple decided to change some of 
 the syntax... breaking the earlier templates.
I've promised to include Xcode 2.x support next time, but it seems that this template still uses GCC 3.3 ? --anders
Oct 02 2006
next sibling parent Fredrik Olsson <peylow gmail.com> writes:
Anders F Björklund skrev:
 Fredrik Olsson wrote:
 
 The support files for Xcode are hidden in:
 /Library/Application Support/Apple/Developer Tools/
 A quite long but logical path.
Paths with spaces in them suck eggs, logical or not. /Library/Application\ Support/Apple/Developer\ Tools
I think we can blame the lowest denominator here. Just as UTF8 how logical and good it ever is, fails unless all tools in the chain has support for it. A chain is never stronger than the weakest link :(.
 It is a project template for a tool application in D. It solves a few 
 problems present in Xcode 2.2 and later. Apple decided to change some 
 of the syntax... breaking the earlier templates.
I've promised to include Xcode 2.x support next time, but it seems that this template still uses GCC 3.3 ?
I do not think so, I believe it is merely a strange naming convention. GDC 3.3, when in practice it will use whatever the gdc is symlinked to. Or that could be my setup, it has been patched over a long time. And I am not quite sure how one would set it up from scratch any longer. I will have to look into that. // Fredrik Olsson
 --anders
Oct 02 2006
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Anders F Björklund wrote:
 Fredrik Olsson wrote:
 
 The support files for Xcode are hidden in:
 /Library/Application Support/Apple/Developer Tools/
 A quite long but logical path.
Paths with spaces in them suck eggs, logical or not. /Library/Application\ Support/Apple/Developer\ Tools
I hear some folks have fixed this with symbolic links. It's uggg-leee, but at least works. cd /Library ln -s Application\ Support Application_Support cd Application_Support/Apple ln -s Developer\ Tools Developer_Tools etc... One would think that if anything, developer tools and their directory are both created and maintained by programmers, and they if anybody _should_ know better. Oh, well.
Oct 02 2006
parent reply Fredrik Olsson <peylow gmail.com> writes:
Georg Wrede skrev:
 Anders F Björklund wrote:
 Fredrik Olsson wrote:

 The support files for Xcode are hidden in:
 /Library/Application Support/Apple/Developer Tools/
 A quite long but logical path.
Paths with spaces in them suck eggs, logical or not. /Library/Application\ Support/Apple/Developer\ Tools
I hear some folks have fixed this with symbolic links. It's uggg-leee, but at least works. cd /Library ln -s Application\ Support Application_Support cd Application_Support/Apple ln -s Developer\ Tools Developer_Tools etc... One would think that if anything, developer tools and their directory are both created and maintained by programmers, and they if anybody _should_ know better. Oh, well.
Or one could look at it as a choice between: 1. Give up progress, and hold onto legacy. 2. Give up current conveniences, and aim for brighter future. Sort of like D. Using it means giving up some conveniences to gain others. The early adopters will take the hit, but unless someone is willing to take that hit everyone will stay in caves... // Fredrik Olsson
Oct 02 2006
parent Georg Wrede <georg.wrede nospam.org> writes:
Fredrik Olsson wrote:
 Georg Wrede skrev:
 
 Anders F Björklund wrote:

 Fredrik Olsson wrote:

 The support files for Xcode are hidden in:
 /Library/Application Support/Apple/Developer Tools/
 A quite long but logical path.
Paths with spaces in them suck eggs, logical or not. /Library/Application\ Support/Apple/Developer\ Tools
I hear some folks have fixed this with symbolic links. It's uggg-leee, but at least works. cd /Library ln -s Application\ Support Application_Support cd Application_Support/Apple ln -s Developer\ Tools Developer_Tools etc... One would think that if anything, developer tools and their directory are both created and maintained by programmers, and they if anybody _should_ know better. Oh, well.
Or one could look at it as a choice between: 1. Give up progress, and hold onto legacy. 2. Give up current conveniences, and aim for brighter future. Sort of like D. Using it means giving up some conveniences to gain others. The early adopters will take the hit, but unless someone is willing to take that hit everyone will stay in caves...
I was thinking more like, let the lusers have their files and directories with spaces all over, but let the compiler tools directories have underscores -- because all of us _will_ encounter some programming tools we'd like to use, and which are too old to handle the spaces. Ah -- and about
 Or one could look at it as a choice between:
 1. Give up progress, and hold onto legacy.
 2. Give up current conveniences, and aim for brighter future.
We're all aiming for a better future. But it's not wise to jump into incompatibility, however lofty our goals are. --- I'm not forcing anybody here, it just was a hint if someone is forced to use such legacy tools.
Oct 02 2006