• Charles Kerr (8/8) Sep 29 2006 Does anyone have a a set of recent instructions and files to get D
• Fredrik Olsson (10/18) Oct 02 2006 The support files for Xcode are hidden in:
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (6/12) Oct 02 2006 Paths with spaces in them suck eggs, logical or not.
• Fredrik Olsson (10/27) Oct 02 2006 I think we can blame the lowest denominator here. Just as UTF8 how
• Georg Wrede (11/20) Oct 02 2006 I hear some folks have fixed this with symbolic links.
• Fredrik Olsson (8/33) Oct 02 2006 Or one could look at it as a choice between:
• Georg Wrede (11/52) Oct 02 2006 I was thinking more like, let the lusers have their files and

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.
-- 

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

=?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

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

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.

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

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.