Closed felix91gr closed 6 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...
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:
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 :)
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.
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 .
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.
Yay! Thank you :)
I'm now beginning the transition from
Xcode.swift
toXcodeEdit
forSourceKittenDaemon
. 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.Comparing
PBXObjects
: we have the following line in SKD:Here we get an error:
'id' is inaccessible due to 'internal' protection level
The
string
function is inaccessible:Error is:
'string' is inaccessible due to 'internal' protection level
Same problem with
allObjects
:And with AllObjects's
fullFilePaths
. I could see this one after makingallObjects
public
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 apublic
getter property if I'm not mistaken.Thanks in advance :)