tomlokhorst / XcodeEdit

Swift library for reading and writing Xcode project files in OpenStep format
MIT License
206 stars 38 forks source link

[Usage question, not an issue] How to correctly compare PBXObjects? (and other questions) #24

Closed felix91gr closed 6 years ago

felix91gr commented 7 years ago

I'm now beginning the transition from Xcode.swift to XcodeEdit for SourceKittenDaemon. Since between both there are API changes, there are some parts of SKD that fail to compile, and I want to ask about how should we use the new API to replace those parts.

All the problems that I get are because of internal access restrictions.

  1. Comparing PBXObjects: we have the following line in SKD:

    return objects.filter { $0.buildPhase.id == phase.id }

    Here we get an error: 'id' is inaccessible due to 'internal' protection level

  2. The string function is inaccessible:

    let type = fileRef.string("lastKnownFileType")

    Error is: 'string' is inaccessible due to 'internal' protection level

  3. Same problem with allObjects:

    let relativePath = self.xcProjectFile.project.allObjects.fullFilePaths[fileRef.id]
  4. And with AllObjects's fullFilePaths. I could see this one after making allObjects public

    let relativePath = self.xcProjectFile.project.allObjects.fullFilePaths[fileRef.id]

If the intent was to make these fields readable, then the first 3 can be fixed using the public keyword (because they are essentially immutable) and since the 4th one is mutable, it should be wrapped with a public getter property if I'm not mistaken.

Thanks in advance :)

tomlokhorst commented 7 years ago

I don't think there are any API changes between Xcode.swift and XcodeEdit, it was just a rename. But I did notice the fork of Xcode.swift you're using made those internal members public. That might be the difference you're seeing.

So the quick fix would be to again fork XcodeEdit and make these public. 😉 However I do want to fix this properly, without the need for a fork:

Some of these internals are implementation details, and intentionally internal. Others I'm less sure about.

I can add a convenience getter var lastKnownFileType: String? to PBXReference, however that should just be a convenience function, since I'm never going to be able to wrap all possible (future) fields. So I think I should probably make PBXObject.fields public, same goes for PBXObject.id.

AllObjects.fullFilePaths is an implementation detail, you should be able to access PBXFileReference.fullPath, without the need for AllObjects.fullFilePaths.

If your looking to migrate anyway, you may want to take a look at the references branch, used in https://github.com/tomlokhorst/XcodeEdit/pull/22. I plan on releasing that branch as XcodeEdit 2.0, since it is a significant refactor and API change. I haven't released it yet, because I haven't fully tested it yet in real-world projects. Unfortunately the current version of SPM makes it hard to point to development branches...

felix91gr commented 7 years ago

Before anything, I wanna thank you for your support with this :) I really appreciate it

However I do want to fix this properly, without the need for a fork

Awesome! When can you do it? I'm gonna make a fork in the meantime (to test how the port to Linux behaves, since it's never been tested before), I can start a PR and then we solve it together that way. Or you can fix it in your own timeframe, and then I reference your release when you put it out. Whatever suits you :) I'll be here to test how the changes affect our code :smile:

felix91gr commented 6 years ago

If your looking to migrate anyway, you may want to take a look at the references branch, used in #22. I plan on releasing that branch as XcodeEdit 2.0, since it is a significant refactor and API change. I haven't released it yet, because I haven't fully tested it yet in real-world projects. Unfortunately the current version of SPM makes it hard to point to development branches...

Sorry for reviving this issue, but... did it go well? Since now you've released 2.0 and 2.1, maybe we can finally use your release directly without the need for a fork :)

tomlokhorst commented 6 years ago

What are your specific needs for version 2.x?

I quickly look through your original question, and I think all the fields you mentioned are now publicly available. The Guid identifier objects used are also comparable for equality.

Also, I'll make a new 2.2 release in a day or so, that fixes all the compactMap warnings.

felix91gr commented 6 years ago

Oh, that’s great! Thanks for making that work.

I’m currently trying to find the cause of a crash with the 1.0 version. I’ve tried to compile it with 2.0, but failed. I’m gonna look more into it, maybe if we make it compile with the 2.0 the crash dissappears :)

On Mon, Apr 2, 2018 at 4:34 PM Tom Lokhorst notifications@github.com wrote:

What are your specific needs for version 2.x?

I quickly look through your original question, and I think all the fields you mentioned are now publicly available. The Guid identifier objects used are also comparable for equality.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tomlokhorst/XcodeEdit/issues/24#issuecomment-378020387, or mute the thread https://github.com/notifications/unsubscribe-auth/ALNBJ0l-mvRXoXr8jlolrjtw7rrhiG4zks5tkn07gaJpZM4Nf-WQ .

tomlokhorst commented 6 years ago

I loaded your Fixture.xcodeproj in the current version of XcodeEdit. It fails to parse because XcodeEdit requires a field defaultConfigurationName on a XCConfigurationList. I think that field should be optional, I've changed that in the current develop version, this will be in the next release.

felix91gr commented 6 years ago

Yay! Thank you :)