↑ ↓ ← → 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
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 ?
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.
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.
Home
| Search
| C & C++
| D
| DMDScript
| News Groups
| index
| prev
| next