Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ruby implementation of xcproj functionality #203

Merged
merged 21 commits into from
Jan 31, 2015
Merged

Conversation

neonichu
Copy link
Member

@neonichu neonichu commented Oct 7, 2014

see #199

output = `#{command} 2>&1`
success = $?.exitstatus.zero?
[success, output]
XCODE_PATH = Pathname.new('/Applications/Xcode.app/Contents')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hardcoding the Xcode path is not good. In my /Applications directory, I have

  • Xcode4.app
  • Xcode502.app
  • Xcode511.app
  • Xcode6.app
  • Xcode61.app

but no Xcode.app.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. I always like using xcode-select -p for this purpose

@alloy
Copy link
Member

alloy commented Oct 8, 2014

Awesome work!

Be sure to take a look at this comment, though: #199 (comment)

$stderr.reopen orig_stderr
end
retval
end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What type of output is this actually silencing? Can you paste an example?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lots of load errors for plugins, because we are initialising the IDE without actually being the IDE.

@neonichu
Copy link
Member Author

neonichu commented Oct 8, 2014

@alloy it doesn't write, though, it just touches, so it felt more appropriate to have it keep the existing API.

@alloy
Copy link
Member

alloy commented Oct 8, 2014

@alloy it doesn't write, though, it just touches, so it felt more appropriate to have it keep the existing API.

What I gathered from the discussions with @0xced is that that approach is the only way that we are vulnerable to the unicode character crippling bug. i.e. we should skip the XML plist completely where possible and write to ASCII immediately.

@alloy
Copy link
Member

alloy commented Oct 8, 2014

And regardless of immediately vs touching, there need to be safeguards against not finding the frameworks, not being able to dlopen them, symbols not being found, and runtime errors, so that we can gracefully fallback.

@neonichu
Copy link
Member Author

neonichu commented Oct 8, 2014

Oh yes, totally - this is just an initial step.

As for directly writing, I don't see how we could do that without completely relying on a PBXProject instance for reading, which would be a much more massive endeavour.

@0xced
Copy link
Contributor

0xced commented Oct 8, 2014

There is no need to rely on PBXProject for reading, this work is already done. The RubyHashPropertyListWrite method should just be changed to this (pseudo code):

RubyHashPropertyListWrite(hash, path)
  plist = RubyHashToCFDictionary(hash)
  data = objc_msgSend(plist, sel_registerName("plistDescriptionUTF8Data")) # whatever the syntax is with fiddle
  write `data` (with whatever conversion is needed from NSData) to `path`

@neonichu
Copy link
Member Author

neonichu commented Oct 8, 2014

@0xced awesome 👍

@alloy
Copy link
Member

alloy commented Oct 8, 2014

Right, that’s the version I meant. Thanks, @0xced.

Except of course that RubyHashPropertyListWrite shouldn’t be modified, as it should be the version that we fallback to when all else with private APIs fail.

@neonichu
Copy link
Member Author

neonichu commented Oct 8, 2014

So I'd say we actually put this into PlistHelper as another strategy, as initially proposed in @alloy's comment. Do we get rid off XCProjHelper entirely, or still keep it around for cases where our internal writing fails, but xcproj might succeed?

@alloy
Copy link
Member

alloy commented Oct 8, 2014

So I'd say we actually put this into PlistHelper as another strategy, as initially proposed in @alloy's comment.

👍

Do we get rid off XCProjHelper entirely, or still keep it around for cases where our internal writing fails, but xcproj might succeed?

I think we can get rid of it completely. The chance of one working but the other failing is slim afaik and only means more code in our codebase.

instance,
CoreFoundation.NSSelectorFromString(CoreFoundation.RubyStringToCFString('respondsToSelector:')),
selector)
result == CoreFoundation::TRUE ? true : false
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CoreFoundation.CFBooleanToRubyBoolean(result)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's actually not a CFBoolean, just a BOOL

@kylef
Copy link
Contributor

kylef commented Nov 7, 2014

This needs a rebase before it can be merged.

@segiddins
Copy link
Member

@neonichu @alloy @kylef should this go into 0.36 or no?

@segiddins
Copy link
Member

@neonichu ping

@neonichu
Copy link
Member Author

@segiddins IDK, seems to me that there is little interest in merging this, so probably should just be closed.

@kylef
Copy link
Contributor

kylef commented Jan 12, 2015

@neonichu There is certainly interest in getting this into master. We've been waiting for you to rebase this branch before it's even mergable.

screen shot 2015-01-12 at 16 39 14

Along with addressing the outstanding comments.

@neonichu neonichu force-pushed the pbxproject-write-💥 branch 2 times, most recently from 1c58a7f to 1fd9cbb Compare January 12, 2015 16:49
@segiddins
Copy link
Member

Well done @neonichu! Let's review this one more time, and then get this into the final 0.36 release!

@neonichu
Copy link
Member Author

@kylef sorry, I thought I had done that already, but turns out I merged master into this instead of doing a rebase. ¯_(ツ)_/¯

@kylef kylef self-assigned this Jan 16, 2015
@@ -70,6 +76,24 @@ def file_in_conflict?(path)
ensure
file.close
end

def ruby_hash_write_xcode(hash, path)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@neonichu Could you add some documentation to this stating which type this method expects. I.e, path being a pathname or string etc.

@neonichu neonichu force-pushed the pbxproject-write-💥 branch from 5dacc71 to 0525ef1 Compare January 31, 2015 22:08
kylef added a commit that referenced this pull request Jan 31, 2015
Ruby implementation of xcproj functionality
@kylef kylef merged commit 3e1c0c7 into master Jan 31, 2015
@kylef kylef deleted the pbxproject-write-💥 branch January 31, 2015 22:19
@neonichu
Copy link
Member Author

@orta
Copy link
Member

orta commented Jan 31, 2015

awesome

@coveralls
Copy link

Coverage Status

Changes Unknown when pulling 5fb3e42 on pbxproject-write-💥 into * on master*.

devxoul referenced this pull request in CocoaPods/guides.cocoapods.org Jun 16, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants