www.digitalmars.com         C & C++   DMDScript  

D.gnu - Getting gdc working with xcode 3.1

reply ylixir <ylixir gmail.com> writes:
Today i managed to get gdc compiled and working with the version of gcc 
that comes with xcode 3.1.

i haven't found anyplace that puts together all you need to do to get 
gdc working with leopard. especially if you want ppc support. so i made 
one hoping that the next person will experience a little less pain than 
i did. site is here:

http://sites.google.com/site/ylixir/projects/gdc-on-a-mac

p.s. i put some patches up there that i don't really know where to 
submit for inclusion in the main gdc project.  specifically a patch for 
the patches that gdc does to apples compiler, and a patch for the apples 
linker. anyone know where i should go about submitting those?
Sep 17 2008
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
ylixir wrote:

 Today i managed to get gdc compiled and working with the version of gcc 
 that comes with xcode 3.1.
 
 i haven't found anyplace that puts together all you need to do to get 
 gdc working with leopard. especially if you want ppc support. so i made 
 one hoping that the next person will experience a little less pain than 
 i did. site is here:
 
 http://sites.google.com/site/ylixir/projects/gdc-on-a-mac


Thanks for the update, I'm still planning to make a
release of "gdcmac" for Leopard and might as well aim
for Xcode 3.1 and gcc-5484 instead of 3.0 and gcc-5465.

Or maybe stick with the original "plan" and go straight
for gcc_42 instead, for the fictional GDC 0.25 release ?
Along with upgrading MinGW's GCC to 4.2.1, for "gdcwin"...

"gdcgnu" will probably wait for GCC 4.3.0, with Fedora 9.


 p.s. i put some patches up there that i don't really know where to 
 submit for inclusion in the main gdc project.  specifically a patch for 
 the patches that gdc does to apples compiler, and a patch for the apples 
 linker. anyone know where i should go about submitting those?


Here on the NG as good a place as any, as far as I know.

Or file another bug report upstream, but those then risk
being annoyances and closed as "dupe" rather than helpful.
But I think the Apple linker bug also affected e.g. GHC ?

I included the patch and a binary in the package meanwhile.

--anders
Sep 18 2008
next sibling parent ylixir <ylixir gmail.com> writes:
Anders F Björklund wrote:


 Thanks for the update, I'm still planning to make a
 release of "gdcmac" for Leopard and might as well aim
 for Xcode 3.1 and gcc-5484 instead of 3.0 and gcc-5465.
 
 Or maybe stick with the original "plan" and go straight
 for gcc_42 instead, for the fictional GDC 0.25 release ?
 Along with upgrading MinGW's GCC to 4.2.1, for "gdcwin"...


big smiles either way

:-D



 But I think the Apple linker bug also affected e.g. GHC ?


ghc = haskell?
Sep 18 2008
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2008-09-18 04:38:49 -0400, Anders F Björklund <afb algonet.se> said:


 Thanks for the update, I'm still planning to make a
 release of "gdcmac" for Leopard and might as well aim
 for Xcode 3.1 and gcc-5484 instead of 3.0 and gcc-5465.
 
 Or maybe stick with the original "plan" and go straight
 for gcc_42 instead, for the fictional GDC 0.25 release ?
 Along with upgrading MinGW's GCC to 4.2.1, for "gdcwin"...


Anything that runs out of the box with no show stopper is an 
improvement from what we have now.

I've been trying too to build a working GDC with the intent of creating 
a D for Xcode package including the compiler, debugger, linker and my D 
for Xcode plugin with some project and file templates all together for 
easy installation. I want to distribute a universal binary compiler 
capable of PowerPC and Intel output, but I haven't had much success in 
compiling it up to now.

My current approach is to compile four compilers (PowerPC to PowerPC, 
PowerPC to Intel, Intel to Intel, and Intel to PowerPC) and merge 
executables into universal binaries using lipo. But I haven't been able 
to compile anything but the first variant (PowerPC to PowerPC). Do you 
have any tip for doing the rest, as you seem to have acheived it 
somehow for gdcmac?

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Sep 19 2008
next sibling parent ylixir <ylixir gmail.com> writes:
Yeah, what I wound up with was two sets of binaries, both universal 
binaries, one targeting intel and one targeting ppc.

i would reccomend going to the site linked in my original post and doing 
steps two and three, that will give you a patched linker and a destroot 
directory structure with the whole works in it that you can make a 
package out of, without impacting your system as a whole.

if you don't want to do that, the gist of what i did is below, but if 
you have specific problems let me know.  worst case i can zip up my 
destroot and e-mail it, or upload it to my google site for a few days so 
you can download.

you can get all my patches and scripts from the link in the original 
post, you'll need the one for the linker and for the actual compiler, 
unless you already made your own which maybe you did if you already have 
the ppc->ppc part working. i also modified dave cheney's script that 
basically automates the whole build/patch process for the compiler, 
again, see the page linked above.

basically what i did was patch and replace my linker (ld64) before 
anything else, to avoid those nasty bus errors that keep cropping up. 
note that ld64 is symlinked to ld, so replacing ld replaces both.

next step is patching the patches that gdc applies to apples compiler. 
then using the setup-gcc.sh script (more info in the INSTALL file from 
dgcc).

from there i stopped paying attention to dgcc's instructions and 
switched to the instructions in the README.Apple file that comes with 
apples gcc source.

Building the apple way is pretty easy, and does all the dirty work for 
you, no lipo etc. all you do is make a destination, object, and symlink 
directory, then execute the build command. here is the command line from 
my script:

sudo gnumake install RC_OS=macos \
	SRCROOT=`pwd` OBJROOT=`pwd`/build/obj \
	DSTROOT=$DESTROOT SYMROOT=`pwd`/build/sym

this command should by default build host and target compilers for both 
platforms, and install them to the place pointed to by DSTROOT. then you 
can ditto it like i did to install on your system, or make a package 
from it, or whatever.

p.s. i had to use sudo because apple automatically makes root the owner 
of all the executables and stuff.

p.p.s. if you don't use the script to build the compiler, it's still a 
good reference on how to apply the patches, and how to run the build

Michel Fortin wrote:

 On 2008-09-18 04:38:49 -0400, Anders F Björklund <afb algonet.se> said:
 

 Thanks for the update, I'm still planning to make a
 release of "gdcmac" for Leopard and might as well aim
 for Xcode 3.1 and gcc-5484 instead of 3.0 and gcc-5465.

 Or maybe stick with the original "plan" and go straight
 for gcc_42 instead, for the fictional GDC 0.25 release ?
 Along with upgrading MinGW's GCC to 4.2.1, for "gdcwin"...


 
 Anything that runs out of the box with no show stopper is an improvement 
 from what we have now.
 
 I've been trying too to build a working GDC with the intent of creating 
 a D for Xcode package including the compiler, debugger, linker and my D 
 for Xcode plugin with some project and file templates all together for 
 easy installation. I want to distribute a universal binary compiler 
 capable of PowerPC and Intel output, but I haven't had much success in 
 compiling it up to now.
 
 My current approach is to compile four compilers (PowerPC to PowerPC, 
 PowerPC to Intel, Intel to Intel, and Intel to PowerPC) and merge 
 executables into universal binaries using lipo. But I haven't been able 
 to compile anything but the first variant (PowerPC to PowerPC). Do you 
 have any tip for doing the rest, as you seem to have acheived it somehow 
 for gdcmac?
Sep 19 2008
prev sibling next sibling parent reply ylixir <ylixir gmail.com> writes:
just a quick correction of my previous post, actually i checked, and i 
have three sets of binaries, all universal, one that targets intel, one 
that targets ppc, and one that targets either, depending on the -arch 
switch, so i'm guessing that is exactly what you need.

Michel Fortin wrote:

 On 2008-09-18 04:38:49 -0400, Anders F Björklund <afb algonet.se> said:
 

 Thanks for the update, I'm still planning to make a
 release of "gdcmac" for Leopard and might as well aim
 for Xcode 3.1 and gcc-5484 instead of 3.0 and gcc-5465.

 Or maybe stick with the original "plan" and go straight
 for gcc_42 instead, for the fictional GDC 0.25 release ?
 Along with upgrading MinGW's GCC to 4.2.1, for "gdcwin"...


 
 Anything that runs out of the box with no show stopper is an improvement 
 from what we have now.
 
 I've been trying too to build a working GDC with the intent of creating 
 a D for Xcode package including the compiler, debugger, linker and my D 
 for Xcode plugin with some project and file templates all together for 
 easy installation. I want to distribute a universal binary compiler 
 capable of PowerPC and Intel output, but I haven't had much success in 
 compiling it up to now.
 
 My current approach is to compile four compilers (PowerPC to PowerPC, 
 PowerPC to Intel, Intel to Intel, and Intel to PowerPC) and merge 
 executables into universal binaries using lipo. But I haven't been able 
 to compile anything but the first variant (PowerPC to PowerPC). Do you 
 have any tip for doing the rest, as you seem to have acheived it somehow 
 for gdcmac?
Sep 19 2008
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2008-09-19 12:39:05 -0400, ylixir <ylixir gmail.com> said:


 just a quick correction of my previous post, actually i checked, and i 
 have three sets of binaries, all universal, one that targets intel, one 
 that targets ppc, and one that targets either, depending on the -arch 
 switch, so i'm guessing that is exactly what you need.


Oh! Great.

I didn't realize your script was actually doing what I want. I'll give 
it a try. Thanks.

(And perhaps I should have read Apple's documentation more carefully too.)

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Sep 19 2008
parent ylixir <ylixir gmail.com> writes:
Michel Fortin wrote:

 On 2008-09-19 12:39:05 -0400, ylixir <ylixir gmail.com> said:
 

 just a quick correction of my previous post, actually i checked, and i 
 have three sets of binaries, all universal, one that targets intel, 
 one that targets ppc, and one that targets either, depending on the 
 -arch switch, so i'm guessing that is exactly what you need.


 
 Oh! Great.
 
 I didn't realize your script was actually doing what I want. I'll give 
 it a try. Thanks.
 
 (And perhaps I should have read Apple's documentation more carefully too.)
 


;-)
Sep 19 2008
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Michel Fortin wrote:


 Thanks for the update, I'm still planning to make a
 release of "gdcmac" for Leopard and might as well aim
 for Xcode 3.1 and gcc-5484 instead of 3.0 and gcc-5465.

 Or maybe stick with the original "plan" and go straight
 for gcc_42 instead, for the fictional GDC 0.25 release ?
 Along with upgrading MinGW's GCC to 4.2.1, for "gdcwin"...


 
 Anything that runs out of the box with no show stopper is an improvement 
 from what we have now.


I'm not aware of any showstoppers on Mac OS X Tiger or
Windows XP, just that Mac OS X Leopard of Windows Vista
hasn't been "supported" with the current package releases.


 My current approach is to compile four compilers (PowerPC to PowerPC, 
 PowerPC to Intel, Intel to Intel, and Intel to PowerPC) and merge 
 executables into universal binaries using lipo. But I haven't been able 
 to compile anything but the first variant (PowerPC to PowerPC). Do you 
 have any tip for doing the rest, as you seem to have acheived it somehow 
 for gdcmac?


I used the Apple version of GCC and built it the Apple way.
And it's actually 4 output targets, including the 64-bit...
Similarly I used the MinGW version of GCC and their script.

--anders
Sep 21 2008
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2008-09-21 13:52:19 -0400, Anders F Björklund <afb algonet.se> said:


 Anything that runs out of the box with no show stopper is an 
 improvement from what we have now.


 
 I'm not aware of any showstoppers on Mac OS X Tiger or
 Windows XP, just that Mac OS X Leopard of Windows Vista
 hasn't been "supported" with the current package releases.


Well, I meant that the latest gdcmac wouldn't run out of the box on Mac 
OS X Leopard. You have to include manually the standard library path 
and the linker doesn't work very well for PowerPC (Apple's fault, I 
know, but still one more thing to figure out and fix). Perhaps 
showstopper was a little harsh; basically, it doesn't "just work" as it 
should, there are still a couple of problems to figure out and solve 
before it works.


 My current approach is to compile four compilers (PowerPC to PowerPC, 
 PowerPC to Intel, Intel to Intel, and Intel to PowerPC) and merge 
 executables into universal binaries using lipo. But I haven't been able 
 to compile anything but the first variant (PowerPC to PowerPC). Do you 
 have any tip for doing the rest, as you seem to have acheived it 
 somehow for gdcmac?


 
 I used the Apple version of GCC and built it the Apple way.
 And it's actually 4 output targets, including the 64-bit...
 Similarly I used the MinGW version of GCC and their script.


Yeah, I know now. I think I've been following the wrong instructions. 
ylixir made me realize that.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Sep 21 2008
next sibling parent reply ylixir <ylixir gmail.com> writes:
Michel Fortin wrote:


 Well, I meant that the latest gdcmac wouldn't run out of the box on Mac 
 OS X Leopard. You have to include manually the standard library path


I  didn't mess with the paths at all, everything just works on my 
system. Is that an issue still for some leopard systems?
Sep 21 2008
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2008-09-21 22:18:03 -0400, ylixir <ylixir gmail.com> said:


 Michel Fortin wrote:
 

 Well, I meant that the latest gdcmac wouldn't run out of the box on Mac 
 OS X Leopard. You have to include manually the standard library path


 
 I  didn't mess with the paths at all, everything just works on my 
 system. Is that an issue still for some leopard systems?


No indeed, not if you build it yourself.

I was talking about problems with the gdcmac build for Tiger available 
on gdcmac.sourceforge.net when it runs on Leopard. Basically the 
problem is that there is currently no installer for a gdc build working 
correctly on Leopard, the current one being for Tiger. It's not really 
a problem for me as I compiled my own version, but it surely is not 
very encouraging for someone who wants to try a new language and the 
only available builds don't work.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Sep 21 2008
parent ylixir <ylixir gmail.com> writes:
Michel Fortin wrote:

 On 2008-09-21 22:18:03 -0400, ylixir <ylixir gmail.com> said:
 

 Michel Fortin wrote:


 Well, I meant that the latest gdcmac wouldn't run out of the box on 
 Mac OS X Leopard. You have to include manually the standard library path


 I  didn't mess with the paths at all, everything just works on my 
 system. Is that an issue still for some leopard systems?


 
 No indeed, not if you build it yourself.
 
 I was talking about problems with the gdcmac build for Tiger available 
 on gdcmac.sourceforge.net when it runs on Leopard. Basically the problem 
 is that there is currently no installer for a gdc build working 
 correctly on Leopard, the current one being for Tiger. It's not really a 
 problem for me as I compiled my own version, but it surely is not very 
 encouraging for someone who wants to try a new language and the only 
 available builds don't work.
 


oh yeah, true for sure. trying to get gdc working on my ibook was like 
ramming my head against a wall. it's frustrating when each failed 
attempt takes an entire day. that's why i made the step by step. if i 
ever have time to read up on how to make a package i'll probably do 
that, and upload it too unless someone beats me to it. no reason for 
people to roll their own compilers imho, especially since some of those 
people are just learning how to write hello world and doing a custom 
build would be basically impossible.

also, i don't feel that xcode 2.5 is really a choice.  ever try to 
compile from the command line with that toolchain?  annoying doesn't 
even begin to describe...

</rant>
Sep 21 2008
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Michel Fortin wrote:


 Well, I meant that the latest gdcmac wouldn't run out of the box on Mac 
 OS X Leopard. You have to include manually the standard library path and 
 the linker doesn't work very well for PowerPC (Apple's fault, I know, 
 but still one more thing to figure out and fix). Perhaps showstopper was 
 a little harsh; basically, it doesn't "just work" as it should, there 
 are still a couple of problems to figure out and solve before it works.


There are packages for those, in the "Leopard" directory of the image...

It'll still use Xcode 2.5 rather than Xcode 3.0, but should limp along.

--anders
Sep 22 2008
prev sibling parent reply Jacob Carlborg <doobnet gmail.com> writes:
Anders F Björklund wrote:

 ylixir wrote:

 Today i managed to get gdc compiled and working with the version of 
 gcc that comes with xcode 3.1.

 i haven't found anyplace that puts together all you need to do to get 
 gdc working with leopard. especially if you want ppc support. so i 
 made one hoping that the next person will experience a little less 
 pain than i did. site is here:

 http://sites.google.com/site/ylixir/projects/gdc-on-a-mac


 
 Thanks for the update, I'm still planning to make a
 release of "gdcmac" for Leopard and might as well aim
 for Xcode 3.1 and gcc-5484 instead of 3.0 and gcc-5465.
 
 Or maybe stick with the original "plan" and go straight
 for gcc_42 instead, for the fictional GDC 0.25 release ?
 Along with upgrading MinGW's GCC to 4.2.1, for "gdcwin"...
 
 "gdcgnu" will probably wait for GCC 4.3.0, with Fedora 9.
 

 p.s. i put some patches up there that i don't really know where to 
 submit for inclusion in the main gdc project.  specifically a patch 
 for the patches that gdc does to apples compiler, and a patch for the 
 apples linker. anyone know where i should go about submitting those?


 
 Here on the NG as good a place as any, as far as I know.
 
 Or file another bug report upstream, but those then risk
 being annoyances and closed as "dupe" rather than helpful.
 But I think the Apple linker bug also affected e.g. GHC ?
 
 I included the patch and a binary in the package meanwhile.
 
 --anders


It would be really nice with a D integration that works with Xcode 3.1
Sep 19 2008
next sibling parent reply Jacob Carlborg <doobnet gmail.com> writes:
Jacob Carlborg wrote:

 Anders F Björklund wrote:

 ylixir wrote:

 Today i managed to get gdc compiled and working with the version of 
 gcc that comes with xcode 3.1.

 i haven't found anyplace that puts together all you need to do to get 
 gdc working with leopard. especially if you want ppc support. so i 
 made one hoping that the next person will experience a little less 
 pain than i did. site is here:

 http://sites.google.com/site/ylixir/projects/gdc-on-a-mac


 Thanks for the update, I'm still planning to make a
 release of "gdcmac" for Leopard and might as well aim
 for Xcode 3.1 and gcc-5484 instead of 3.0 and gcc-5465.

 Or maybe stick with the original "plan" and go straight
 for gcc_42 instead, for the fictional GDC 0.25 release ?
 Along with upgrading MinGW's GCC to 4.2.1, for "gdcwin"...

 "gdcgnu" will probably wait for GCC 4.3.0, with Fedora 9.


 p.s. i put some patches up there that i don't really know where to 
 submit for inclusion in the main gdc project.  specifically a patch 
 for the patches that gdc does to apples compiler, and a patch for the 
 apples linker. anyone know where i should go about submitting those?


 Here on the NG as good a place as any, as far as I know.

 Or file another bug report upstream, but those then risk
 being annoyances and closed as "dupe" rather than helpful.
 But I think the Apple linker bug also affected e.g. GHC ?

 I included the patch and a binary in the package meanwhile.

 --anders


 
 It would be really nice with a D integration that works with Xcode 3.1


And that has support for DSSS and Tango
Sep 19 2008
next sibling parent ylixir <ylixir gmail.com> writes:
Jacob Carlborg wrote:

 Jacob Carlborg wrote:

 Anders F Björklund wrote:

 ylixir wrote:

 Today i managed to get gdc compiled and working with the version of 
 gcc that comes with xcode 3.1.

 i haven't found anyplace that puts together all you need to do to 
 get gdc working with leopard. especially if you want ppc support. so 
 i made one hoping that the next person will experience a little less 
 pain than i did. site is here:

 http://sites.google.com/site/ylixir/projects/gdc-on-a-mac


 Thanks for the update, I'm still planning to make a
 release of "gdcmac" for Leopard and might as well aim
 for Xcode 3.1 and gcc-5484 instead of 3.0 and gcc-5465.

 Or maybe stick with the original "plan" and go straight
 for gcc_42 instead, for the fictional GDC 0.25 release ?
 Along with upgrading MinGW's GCC to 4.2.1, for "gdcwin"...

 "gdcgnu" will probably wait for GCC 4.3.0, with Fedora 9.


 p.s. i put some patches up there that i don't really know where to 
 submit for inclusion in the main gdc project.  specifically a patch 
 for the patches that gdc does to apples compiler, and a patch for 
 the apples linker. anyone know where i should go about submitting 
 those?


 Here on the NG as good a place as any, as far as I know.

 Or file another bug report upstream, but those then risk
 being annoyances and closed as "dupe" rather than helpful.
 But I think the Apple linker bug also affected e.g. GHC ?

 I included the patch and a binary in the package meanwhile.

 --anders


 It would be really nice with a D integration that works with Xcode 3.1


 
 And that has support for DSSS and Tango


and vi support for xcode imho!

i think xcode support is being worked on (not by me though).
Sep 19 2008
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2008-09-19 17:13:57 -0400, Jacob Carlborg <doobnet gmail.com> said:


 And that has support for DSSS and Tango


Which kind of support are you hoping for?

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Sep 19 2008
parent reply Jacob Carlborg <doobnet gmail.com> writes:
Michel Fortin wrote:

 On 2008-09-19 17:13:57 -0400, Jacob Carlborg <doobnet gmail.com> said:
 

 And that has support for DSSS and Tango


 
 Which kind of support are you hoping for?
 


That you can choose to build with "dsss build" or "dsss build target" 
instead of gdc.

I downloaded your D plugin for Xcode 3.0 and tried that with 3.1. It 
kind of worked, the plugin itself worked but not building, I think that 
was because I use the gdc bundle from the tango website and it's build 
with the FSF gcc instead of Apple's gcc. I modified the plugin so it 
(almost) worked with the gdc I have but it didn't work to compile a 
tango app without dsss. I also modified the plugin to use dsss instead 
but Xcode added to many unknown flags to the list of build flags that I 
couldn't find and remove them.
Sep 20 2008
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2008-09-20 06:38:54 -0400, Jacob Carlborg <doobnet gmail.com> said:


 13:57 -0400, Jacob Carlborg <doobnet gmail.com> said:
 

 And that has support for DSSS and Tango


 
 Which kind of support are you hoping for?


 
 That you can choose to build with "dsss build" or "dsss build target" 
 instead of gdc.
 
 I downloaded your D plugin for Xcode 3.0 and tried that with 3.1. It 
 kind of worked, the plugin itself worked but not building, I think that 
 was because I use the gdc bundle from the tango website and it's build 
 with the FSF gcc instead of Apple's gcc.


I had to fix the build process for Xcode 3.1, and this fix isn't on the 
website yet. I'm going to put it there pretty soon. It's already in 
source form in the git repository however.


 I modified the plugin so it (almost) worked with the gdc I have but it 
 didn't work to compile a tango app without dsss. I also modified the 
 plugin to use dsss instead but Xcode added to many unknown flags to the 
 list of build flags that I couldn't find and remove them.


That's where you lose me. Xcode has its own build system which you 
should bypass if you want to make dsss in charge of the build. I think 
what you want is a new target were, just like when you have a makefile, 
the build process is only launched by Xcode but taken care by an 
external tool. Am I right?

If that's what you need, then I suggest you create a new target of type 
"External Target" which you can find in the "Other" category, where the 
description says: "Target that invokes an external build system (e.g., 
make)." Then you change the path to "/usr/bin/make" for the path to 
dsss.

If that's not what you need, then there's something I don't understand 
about what you are trying to do.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Sep 20 2008
parent reply Jacob Carlborg <doobnet gmail.com> writes:
Michel Fortin wrote:

 On 2008-09-20 06:38:54 -0400, Jacob Carlborg <doobnet gmail.com> said:
 

 13:57 -0400, Jacob Carlborg <doobnet gmail.com> said:


 And that has support for DSSS and Tango


 Which kind of support are you hoping for?


 That you can choose to build with "dsss build" or "dsss build target" 
 instead of gdc.

 I downloaded your D plugin for Xcode 3.0 and tried that with 3.1. It 
 kind of worked, the plugin itself worked but not building, I think 
 that was because I use the gdc bundle from the tango website and it's 
 build with the FSF gcc instead of Apple's gcc.


 
 I had to fix the build process for Xcode 3.1, and this fix isn't on the 
 website yet. I'm going to put it there pretty soon. It's already in 
 source form in the git repository however.
 

 I modified the plugin so it (almost) worked with the gdc I have but it 
 didn't work to compile a tango app without dsss. I also modified the 
 plugin to use dsss instead but Xcode added to many unknown flags to 
 the list of build flags that I couldn't find and remove them.


 
 That's where you lose me. Xcode has its own build system which you 
 should bypass if you want to make dsss in charge of the build. I think 
 what you want is a new target were, just like when you have a makefile, 
 the build process is only launched by Xcode but taken care by an 
 external tool. Am I right?
 
 If that's what you need, then I suggest you create a new target of type 
 "External Target" which you can find in the "Other" category, where the 
 description says: "Target that invokes an external build system (e.g., 
 make)." Then you change the path to "/usr/bin/make" for the path to dsss.
 
 If that's not what you need, then there's something I don't understand 
 about what you are trying to do.
 


Yeah I got it to work when I used dsss as an External Target. But what I 
want is to have dsss integrated the same way as gdc is. For example, 
changing build options, adding build flags, when I use an external tool 
the binary isn't placed in the Release/Debug folder and so on.

In the project settings->build there should be build options for dsss, 
rebuild and gdc/gdmd.
Sep 20 2008
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2008-09-20 15:48:41 -0400, Jacob Carlborg <doobnet gmail.com> said:


 Yeah I got it to work when I used dsss as an External Target. But what 
 I want is to have dsss integrated the same way as gdc is. For example, 
 changing build options, adding build flags, when I use an external tool 
 the binary isn't placed in the Release/Debug folder and so on.



 In the project settings->build there should be build options for dsss, 
 rebuild and gdc/gdmd.


But, aren't dsss build options part of the dsss.conf file? Are you 
asking for an editor for a dsss.conf file intergated with Xcode's 
project and target build settings?

Perhaps what you want could work as a new target type custom-made for 
DSSS. I'm not sure how much work this is (note that Apple's Xcode API 
is "private" and undocumented and thus not necessarly easy to work 
with). I can offer some guidance if you want to do it. Right now, in 
the limited free time I got, I'm more interested in other things, such 
as improving Xcode debugger integration, and advancing some of my other 
projects.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Sep 20 2008
parent Jacob Carlborg <doobnet gmail.com> writes:
Michel Fortin wrote:

 On 2008-09-20 15:48:41 -0400, Jacob Carlborg <doobnet gmail.com> said:
 

 Yeah I got it to work when I used dsss as an External Target. But what 
 I want is to have dsss integrated the same way as gdc is. For example, 
 changing build options, adding build flags, when I use an external 
 tool the binary isn't placed in the Release/Debug folder and so on.


 

 In the project settings->build there should be build options for dsss, 
 rebuild and gdc/gdmd.


 
 But, aren't dsss build options part of the dsss.conf file? Are you 
 asking for an editor for a dsss.conf file intergated with Xcode's 
 project and target build settings?


That would be nice. But I thought that you could use dsss without a 
dsss.conf and pass build options on the command line. If I run dsss 
without any options or files it says at the bottom: "All other options 
are passed through to rebuild and ultimately the compiler." but I 
noticed that didn't work using dsss 0.75.


 Perhaps what you want could work as a new target type custom-made for 
 DSSS. I'm not sure how much work this is (note that Apple's Xcode API is 
 "private" and undocumented and thus not necessarly easy to work with). I 
 can offer some guidance if you want to do it. Right now, in the limited 
 free time I got, I'm more interested in other things, such as improving 
 Xcode debugger integration, and advancing some of my other projects.


I think I figured out how to do most of the things I wanted to do anyway 
now, thanks.
Sep 21 2008
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Jacob Carlborg wrote:


 I included the patch and a binary in the package meanwhile.


 It would be really nice with a D integration that works with Xcode 3.1


 
 And that has support for DSSS and Tango


My packages for DSSS and Tango can both be found upstream:

http://svn.dsource.org/projects/dsss/downloads/0.78/dsss-0.78-mac-10.4.dmg

http://downloads.dsource.org/projects/tango/0.99.6/tango-0.99.6-mac-10.4.dmg

They were built with the GDC revision matching DMD 1.0.24:

http://downloads.sourceforge.net/gdcmac/gdc-trunk-r206-mac-10.4.dmg

The packages for Tango 0.99.7 and GDC r229 were delayed...
But would be find at addresses similar to the ones above.

--anders
Sep 21 2008
parent reply ylixir <ylixir gmail.com> writes:
Anders F Björklund wrote:

 Jacob Carlborg wrote:
 

 I included the patch and a binary in the package meanwhile.


 It would be really nice with a D integration that works with Xcode 3.1


 And that has support for DSSS and Tango


 
 My packages for DSSS and Tango can both be found upstream:
 
 http://svn.dsource.org/projects/dsss/downloads/0.78/dsss-0.78-mac-10.4.dmg
 
 http://downloads.dsource.org/projects/tango/0.99.6/tango-0.99.6-mac-10.4.dmg 
 
 
 They were built with the GDC revision matching DMD 1.0.24:
 
 http://downloads.sourceforge.net/gdcmac/gdc-trunk-r206-mac-10.4.dmg
 
 The packages for Tango 0.99.7 and GDC r229 were delayed...
 But would be find at addresses similar to the ones above.
 
 --anders


those are for xcode 2.4/2.5 though, aren't they? not 3.x?
Sep 21 2008
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
ylixir wrote:


 those are for xcode 2.4/2.5 though, aren't they? not 3.x?


Correct.
I tired of fighting the bugs and downgraded back to Tiger.

Rumors has it that Mac OS X 10.5.5 and Xcode 3.1 is better,
so maybe I will give it another try some day in the future.

--anders
Sep 22 2008
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2008-09-19 08:44:41 -0400, Jacob Carlborg <doobnet gmail.com> said:


 It would be really nice with a D integration that works with Xcode 3.1


If you mean a D plugin for Xcode's IDE version 3.1, then I have one... 
it's just not on the website yet, but you can download and compile it 
yourself from my git repository if you want.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Sep 19 2008
parent Jacob Carlborg <doobnet gmail.com> writes:
Michel Fortin wrote:

 On 2008-09-19 08:44:41 -0400, Jacob Carlborg <doobnet gmail.com> said:
 

 It would be really nice with a D integration that works with Xcode 3.1


 
 If you mean a D plugin for Xcode's IDE version 3.1, then I have one... 
 it's just not on the website yet, but you can download and compile it 
 yourself from my git repository if you want.
 


Nice
Sep 20 2008