vim doesn't work with non-standard developer tools location

[jadenb1729@…]

STEPS TO REPRODUCE (pre-install bug):

1. Install Developer Tools in a non-standard location (for me, /Users/Shared/Developer).
   
2. Try to install MacPorts.

EXPECTED: MacPorts installs.

ACTUAL RESULTS: MacPorts fails to install (cannot link against library crt1.10.5o).

Installing the Unix tools (which just installs a bunch of symlinks in /usr) makes this work correctly --but there's more!

STEPS TO REPRODUCE (post-install bug):

1. Try to install vim.

EXPECTED RESULTS: vim builds normally.

ACTUAL RESULTS:

/usr/bin/gcc-4.0 -c -I. -Iproto -DHAVE_CONFIG_H   -I/Users/Shared/Applications/Utilities/MacPorts/include -DMACOS_X_UNIX -no-cpp-precomp -I/Developer/Headers/FlatCarbon  -O -D_FORTIFY_SOURCE=1         -o objects/buffer.o buffer.c
In file included from vim.h:315,
                 from buffer.c:28:
os_mac.h:26:64: error: Quickdraw.h: No such file or directory
os_mac.h:27:24: error: ToolUtils.h: No such file or directory
os_mac.h:28:21: error: LowMem.h: No such file or directory
os_mac.h:29:20: error: Scrap.h: No such file or directory
os_mac.h:30:20: error: Sound.h: No such file or directory
os_mac.h:31:24: error: TextUtils.h: No such file or directory
os_mac.h:33:22: error: OSUtils.h: No such file or directory
os_mac.h:34:20: error: Files.h: No such file or directory
os_mac.h:36:22: error: Script.h: No such file or directory

Placing a symlink from /Developer to /Users/Shared/Developer (thanks, improved symlinks in 10.5!) resolves the problem, but it seems that this shouldn't be necessary.

[tobypeterson]

First part is in the installation instructions - you need the "unix tools" to install MacPorts. This is 100% expected. Now that we have ${developer_dir} we can start patching ports (vim in this case) to work when it's not /Developer. Also, I'm curious - what do you mean about "improved symlinks in 10.5"?

[jadenb1729@…]

Replying to toby@…:

First part is in the installation instructions - you need the "unix tools" to install MacPorts. This is 100% expected. Now that we have ${developer_dir} we can start patching ports (vim in this case) to work when it's not /Developer. Also, I'm curious - what do you mean about "improved symlinks in 10.5"?

I'm sorry, I missed that bit of the installation instructions. Is there a reason that MacPorts itself can't be set up to respect a non-standard location (possibly via some flag to configure)?

I was very tired when I wrote this, and momentarily forgot that symlinks have always been able to target directories (part of the reason we have them). I got it mixed up with Apple's new Time-Machine-supporting directory-targeting hard links.

[tobypeterson]

Many (I'd even say most) ports expect a standard unix layout, and that means having the commands in /usr

For things that do need to look in $DEVELOPER_DIR, that type of change needs to be made on a port-by-port basis, nothing we can do about it in the base system.

[jadenb1729@…]

Replying to toby@…:

Many (I'd even say most) ports expect a standard unix layout, and that means having the commands in /usr

For things that do need to look in $DEVELOPER_DIR, that type of change needs to be made on a port-by-port basis, nothing we can do about it in the base system.

Certainly there's nothing that MacPorts can do about individual ports hard-coding locations, but couldn't the MacPorts installer itself be configured to respect a different layout?

[raimue (Rainer Müller)]

Replying to jadenb1729@…:

Certainly there's nothing that MacPorts can do about individual ports hard-coding locations, but couldn't the MacPorts installer itself be configured to respect a different layout?

The configure script in 1.8 will respect a different developer dir by using the output from xcode-select -print-path. The dmg installer will not handle non-default installations.

[jadenb1729@…]

Replying to raimue@…:

Replying to jadenb1729@…:

Certainly there's nothing that MacPorts can do about individual ports hard-coding locations, but couldn't the MacPorts installer itself be configured to respect a different layout?

The configure script in 1.8 will respect a different developer dir by using the output from xcode-select -print-path. The dmg installer will not handle non-default installations.

Do you mean that the configure script does this automatically, or that it requires a switch? I installed from source, but it still did not install correctly until I placed the symlinks in /usr.

[raimue (Rainer Müller)]

Replying to jadenb1729@…:

Do you mean that the configure script does this automatically, or that it requires a switch? I installed from source, but it still did not install correctly until I placed the symlinks in /usr.

Yes, the installer does it automatically for /Developer. Which symlinks do you mean in /usr? The UNIX tools (gcc, make etc.) should always be installed there, regardless which developer dir you choose.

[jadenb1729@…]

Replying to raimue@…:

Replying to jadenb1729@…:

Do you mean that the configure script does this automatically, or that it requires a switch? I installed from source, but it still did not install correctly until I placed the symlinks in /usr.

Yes, the installer does it automatically for /Developer. Which symlinks do you mean in /usr? The UNIX tools (gcc, make etc.) should always be installed there, regardless which developer dir you choose.

Sorry, I think that I must be being exceptionally obtuse. I don't know what "Yes, the installer does it automatically ..." means. You are right that I mean the symlinks to gcc &c.; and, indeed, I understand that the installer expects to find the tools in /usr, but was just wondering why it has to be that way, rather than allowing it to look in a user-specified directory. Maybe it's just prohibitively hard --I don't know.

[raimue (Rainer Müller)]

Fixed in r64540. The Portfile now always uses the Xcode developer dir you have set in macports.conf.