How do I change /Developer/ to /Applications/Developer/ in OS X

January 31, 2006 3:29 PM

A stupid Apple Xcode question.

I like to keep the directories on my computer organized. I guess I'm the only person in the world who does that.

Anyway, I moved the Developer folder into the Applications folder. My reasoning was Xcode Tools are applications, therefore, I could put them in the Applications folder. Boy, was I wrong.

Long story short, whatever project I try to build in Xcode, any project at all...will not build because of the error: "Task not found at path: /Developer/..."

Apple offers no support for this product, at least, over the phone. The only suggestion from the Apple rep was to reinstall the application. The installer gives the user no chance to specify a directory.

Anyway, is there a way to ask my Macintosh, kindly, if it would please not mind the fact that I would rather enjoy having the Developer folder in the Applications folder?

Maybe a polite sudo command? Is there a registry I could edit?

I don't know why this bothering me so much. I just thought the Mac's "especial," was one could drag and drop folders into other folders without breaking applications.

posted by Colloquial Collision to computers & internet (13 comments total)

A big chunk of the Developer Tools is not applications. Look in the Headers and Makefiles and SDK directories. I'd treat it as a system folder that can only be in one place.

What's the path exactly that it complains about?
posted by cillit bang at 3:59 PM on January 31, 2006

What you're seeing is some script or application or makefile hardcoded to the /Developer path. (Or more likely, many such things hardcoded).

If it were just scripts or makefiles choking, you could try to hunt them down in the /Developer folder and change the paths. For instance, you could grep for '/Developer/', see what pops up, and change it to '/Application/Developer' if it seems appropriate. But if the path was hard-coded into binaries, it seems like it will be much more of a pain.

But I just did that, and it would be a royal pain in the ass to weed through the output, and it's not at all clear it'd really work. Most of what's popping up is documentation -- even if you don't search in the documentation subdirectory.

Unless you are really into hacking, I doubt there is going to be a fix for this. But it'd be nice to be proven wrong, as I'd rather have Developer in Apps, too. (For instance, I suspect a kernel hacker could write a kext that would intercept all filesystem calls to /Developer and redirect them wherever you want. But honestly, who's gonna do that?).

But I suspect that some of the tools in Xcode are sloppily written, and depend completely upon stuff being in /Developer.

Note to Apple: If it's not already the case, all XCode stuff should use a variable ${XCode-Root} (or whatever semantics the language wanted) rather than just blindly assuming it's all in /Developer, and the variable should be configurable or intelligently guessed. But I doubt they really care if it bugs a few of us weirdos.
posted by teece at 4:19 PM on January 31, 2006

Well... this is cheating, but you could do this:

ln -s /Developer /Applications/Developer
/Developer/Tools/SetFile -a V /Developer

That doesn't really move the files, but it does make the "appear" where you want and hide it in the root.
posted by sbutler at 4:21 PM on January 31, 2006

It would be nice if the tools worked the way you want. But in the short term, they don't, and you're not going to gain anything but pain by moving them around. Be pragmatic and leave them where they were.
posted by xil at 4:37 PM on January 31, 2006

Good idea, sbutler, but I'd try it the other way.

Move Developer to Applications. Link that to /Developer. Hide the symlink. It might work. I dunno. I don't want to find out right now, but if you're already in a movin' mood, you could give it a try, Colloquial Collision.

I'm in the middle of a project, I just know if I try it I'm going to accidentally destroy something and ruin my groove.


sudo mv /Developer /Applications

ln -s /Applications/Developer /Developer

/Applications/Developer/Tools/SetFile -P -a V /Developer
posted by teece at 5:00 PM on January 31, 2006

You can't hide symlinks, I've tried :( The 'invisible' flag only applies to directories.
posted by sbutler at 5:35 PM on January 31, 2006

Wait... n/m.
posted by sbutler at 5:38 PM on January 31, 2006

How do you hide a symlink?

Thanks teece, everything worked except that last line.

/Applications/Developer/Tools/SetFile -P -a V /Developer
posted by Colloquial Collision at 8:41 PM on January 31, 2006

Okay, I hid the symlink by adding a . at the beginning of the alias, which breaks Xcode...again.

It also gives the same error.

"Task not found at path: /Developer/Java/Ant/bin/ant"
posted by Colloquial Collision at 9:12 PM on January 31, 2006

Okay...I got it!

I recreated the .hidden file (previously found in other versions of OS X) and added the Developer alias to that file.

So, my last question...(I know, one question a week, &c.)

Should I be worried that I had to recreate a semi-obsolete file? I mean, there is a reason the .hidden file was removed from OS X 10.4.4 in the first place, right?

So to recap:

sudo mv /Developer /Applications

ln -s /Applications/Developer /Developer

And then create the .hidden file and add the Developer alias to it by simply typing

Developer

Thanks for the help everyone!
posted by Colloquial Collision at 9:28 PM on January 31, 2006

CC: I made it hide the symlink on my machine, but I had to be careful. I use tab-completion like mad -- by default, in the SetFile command, when I hit 'tab' to complete the symlink name, it automatically added the '/' to the end of the name.

That slash can't be there -- if it is, SetFile follows the symlink and sets the folder it pointed to as hidden. But if the slash is left off, the symlink itself was set as hidden.

That seems like mildly buggy behavior to me (I mean -P says explicitly not to follow symlinks), but hey ... *shrug*
posted by teece at 9:55 PM on January 31, 2006

Now that makes sense. Thank you for your help.
posted by Colloquial Collision at 3:59 AM on February 1, 2006

UPDATE 6 MAY 2006:

This isn't a good idea after all.

If you do this, don't plan on using DarwinPorts or Fink.
posted by Colloquial Collision at 10:31 PM on May 6, 2006