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

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

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

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

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.

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

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.