Trouble with an Install build
Trouble with an Install build
- Subject: Trouble with an Install build
- From: Michael Cashwell <email@hidden>
- Date: Tue, 14 Sep 2004 12:46:02 -0400
Greetings all,
I've spent the morning fighting with an install build. My installed products are a mach_init.d plist file, a daemon, a IOKit driver kext, and a pref pane bundle. Where I've been having problems is getting the install build (done via "sudo xcodebuild ... install") to produce a distribution hierarchy that's ready to be packaged up. I've been having two problems:
1: Getting the correct permissions on intervening directories. For example, the pref pane needs to go to "/Library/PreferencePanes/" and I have Xcode creating that hierarchy except that it uses root:wheel and no group-write permissions on "/Library" and "/Library/PreferencePanes/". That does not agree with what's already there. (I've tried turing off
IFPkgFlagOverwritePermissions and that handles the permissions issue. But the installer still insists on changing the owner and group of these intervening directories.
Why it does this is beyond me, but the upshot is that I must get the install hierarchy exactly as desired before making the package. I have some shell script steps to do this but it feels like a hack. I would prefer to capture such things in the project. In other words, it's bad to specify that these directories need to exist (via a $LOCAL_LIBRARY_DIR)/PreferencePanes/ install path) and yet have to control the owner/group/permissions for those parent directories in a completely separate place.
I've explored the ability to change the owner/group and perms. in the build style UI but I want different settings for the parent directories and the actual bundle items themselves. Any ideas here would be appreciated.
2: Xcode seems to want to litter both the build products and install paths with symlinks to the executables. I cannot figure out why it's creating these links. For example, the preference pane bundle (in addition to the correct "Contents" directory) has a symlink that points back to the parent bundle dir. Similarly, the driver kext bundle (also as a peer to the Contents directory) has a link back to the parent kext bundle dir.
These links are being included in the installation package and that's not right. I could strip them out right before making the installer package (just as I had to tweak the owner/group and perms to work around problem 1 above) but doing so seems like yet another a hack. Can someone explain why Xcode is making these unneeded links and how I might persuade it to stop?
Thanks,
Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden