moretension / duti

A command-line tool to select default applications for document types and URL schemes on Mac OS X
Other
1.41k stars 66 forks source link

duti not compatible with Yosemite #6

Closed kfinlay closed 9 years ago

kfinlay commented 9 years ago

Please see discussion here: https://github.com/Homebrew/homebrew/issues/33009 . Since there's a direct call to Xcode.app in aclocal.m4, the non-beta Xcode has the wrong SDK for beta Yosemite. I will submit an pull request. Might not work until a couple weeks when Yosemite and Xcode 6.1 leave beta.

kfinlay commented 9 years ago

Fixed downstream here: https://github.com/Homebrew/homebrew/pull/33011

dickguertin commented 8 years ago

I've run into troubles with "make" of duti on Yosemite. First, I'm on 10.10.5, and got Xcode soon after I got Yosemite. Then the "App Store" auto-updated my Xcode, and I got "MacOSX10.11.sdk" replacing the original 10.10 version. So the "make" failed miserably. My remedy was to create a symlink called MacOSX10.10.sdk pointing at the 10.11 version. That worked, but two (2) routines compiled with Warning errors. One was in "plist.c" which was easy to fix (line 65, change "From" to 'With"). The other was in "handler.c", as follows:

gcc -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk -mmacosx-version-min=10.10 -Wall -Wmissing-prototypes -g -O2 -c ./handler.c ./handler.c:579:11: warning: 'LSGetApplicationForInfo' is deprecated: first deprecated in OS X 10.10 - Use LSCopyDefaultApplicationURLForContentType instead. [-Wdeprecated-declarations] err = LSGetApplicationForInfo( kLSUnknownType, kLSUnknownCreator, cf_ext, ^ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LSInfoDeprecated.h:631:1: note: 'LSGetApplicationForInfo' has been explicitly marked deprecated here LSGetApplicationForInfo 1 warning generated.

The recommend fix "LSCopyDefaultApplicationURLForContentType" requires re-coding, not replacement. That might require #if-testing within the c-module, where currently there is no testing.

dickguertin commented 8 years ago

I believe I've engineered a fix for having a different version of MacOSX10.1?.sdk on Yosemite, as I reported yesterday. I eliminated my symlink, allowing MacOSX10.11.sdk to stand alone, and modified "configure". Basically, I moved the test on $macrosx_sdk further ahead. Then I modified the assignment of MacOSX for host 10.10 to use an "ls -1d" command with a question-mark in the name to allow match on 10.1? which picks up 10.10, 10.11, etc. I then added code to test the existence of the .sdk file. This insures the .sdk exists on ANY host. Here are the changes:

2996c2996
<      sdk_path="${sdk_path}/MacOSX10.10.sdk"
---  
>      sdk_path=$(ls -1d $sdk_path/MacOSX10.1?.sdk 2>/dev/null | head -n 1)
3000a3001
>      sdk_path=""
3003,3006c3004
<     if test -z "$macosx_sdk"; then
<  macosx_sdk=$sdk_path
<     fi
<
---
>  if test -z "$sdk_path"; then sdk_path="/MacOSX.${host_os}"; fi

3007a3006,3012
>  if test ! -e "$sdk_path"; then
>     as_fn_error $? "${sdk_path} does not exist" "$LINENO" 5
>  fi
>
>  if test -z "$macosx_sdk"; then
>     macosx_sdk=$sdk_path
>  fi

The block of code from 2995 though 3012 (renumbered), looks lke this:

 darwin14*)
     sdk_path=$(ls -1d $sdk_path/MacOSX10.1?.sdk 2>/dev/null | head -n 1)
     macosx_arches=""
     ;;
 *)
     as_fn_error $? "${host_os} is not a supported system" "$LINENO" 5
     sdk_path=""
    esac

 if test -z "$sdk_path"; then sdk_path="/MacOSX.${host_os}"; fi

 if test ! -e "$sdk_path"; then
    as_fn_error $? "${sdk_path} does not exist" "$LINENO" 5
 fi

 if test -z "$macosx_sdk"; then
    macosx_sdk=$sdk_path
 fi