xcodebuild SKIP_INSTALL

[Ryan Schmidt]

On Jun 13, 2016, at 3:35 AM, Alexey Kuznetsov wrote:

> On Mon, Jun 13, 2016 at 7:50 AM, Ryan Schmidt wrote:
> 
>> On Jun 12, 2016, at 9:34 AM, Alexey Kuznetsov wrote:
>>> 
>>> I'm updating MenuMeters port file to the latest OS X El Capitan os version. And it face few issues. I solve them, but not sure if it is best practice.
>>> 
>>> First) of all 'xcode.destroot.settings SKIP_INSTALL=YES' seems ignored by xcodebuild and xcode trying to install .prefsPane into /opt/local/.../home/Library with (Operation not permitted).
>>> 
>>> I solve this, but patching project file:
>>> 
>>> https://github.com/axet/macports_custom/blob/master/aqua/MenuMeters/files/skip_install.patch
>>> 
>>> Seems like hacky solution, please correct me if I'm wrong.
>>> 
>>> Second) final step which includes copying MenuMeters.prefPane into /Library/PreferencePanes copy symbolic link of MenuMeters.prefPane instead content of 'MenuMeters.prefPane'.
>>> 
>>> I solve this by reading value of symbolic link and copying it's original content.
>>> 
>>> https://github.com/axet/macports_custom/blob/master/aqua/MenuMeters/Portfile
>>> 
>>> Correct me here as well.
>> 
>> You should use the github portgroup instead of reimplementing its functionality in your portfile.
> 
> Thank you. Fixed.
> 
>> 
>> 
>> Yes, I've had to edit Xcode project files to remove settings that don't make sense for MacPorts. I don't know if there's a better way.
> 
> Seems like macports recommend to use xcode.destroot.settings
> technique, and it seems failed. Is it macport bug then or latest xcode
> breaks something?
> 
> https://guide.macports.org/chunked/reference.portgroup.html

I don't know. Maybe neither. My assumption has been that using xcode.build.settings and xcode.destroot.settings would work to set settings that are not set by the Xcode project, but that if they are set by the Xcode project, then the settings in the Xcode project override those on the command line, but I have not tested that assumption.


>> I don't know why it would create a symlink instead of copying the actual file. I haven't looked at this particular project's Xcode project file.
> 
> It does it because 'file copy' points to a soft symlink (that what
> build system create in output folder soft symlink to some output
> folder). Seems like double job for a developer to check if it actual
> folder or a symlink and run 'file copy' depend on what type of file is
> that. May be we need help from macport build system to copy
> symlink/folder command ?
> 
>  set from ${worksrcpath}/build/Release/${name}.prefPane
>  set to ${destroot}/Library/PreferencePanes
> 
> copy(from, to) {
>  if {[file type ${from}] == "link"} {
>    file copy [file readlink ${from}] ${to}
>  } else {
>    file copy ${from} ${to}
> }
> }

I don't think this situation has arisen before, or certainly not often. So it's not something for which we would add specific support to MacPorts base. I don't think it's appropriate at this point to redefine the MacPorts base "copy" function to mean "copy the file, unless it's a symlink, in which case copy what the symlink points to". There may be existing ports or parts of base that rely on "copy" copying an actual symlink, since that's what "copy" has done up to now. If this particular port's build system creates a symlink to a file, but you need to install the file it points to, then it's appropriate to write code into this portfile to copy the real file instead, or if the real filename is not known in advance, to discover it with readlink as you suggested above.