I had this idea of making a command line utility similar to the rails setup application.
It should automatically create a Xcode project, setup unit test, setup Frank, install most used Cocoapods and setup a project structure.
There is no such thing at the moment and I would really like to have it and open source it.
I struggled around the other questions here yesterday but found nothing up to date.
I came up with the idea using XcodeProj which is used by CocoaPods to generate a project containing the Pods. So it should not be impossible to do. I also found XcodeProject but this seems to be read-only.
Can someone (maybe of the Cocoapods developers) give me a hint where to start, because the Xcodeproj gem is very undocumented.
To the best place to start to use Xcodeproj is the Xcodeproj::Project class.
Once you open a project the Xcodeproj API allows to edit all the known attributes easily. However you need to keep in mind the following concepts:
If an attribute is a String you can edit it directly.
If an attribute stores an object it is necessary to ask the project to create a new one so it is has the chance to assign an UUID.
If you are editing an attribute which stores a list of objects it is safe only to use the method exposed by the ObjectList.
Xcodeproj performs type checking when you assign values to attributes.
The following lightly tested code should help to get you started by creating a new project named Test with a target named App for a deployment target of iOS 6.0 that adds Class.h and Class.m file to the project, ensuring Class.m is included in the target.
require 'xcodeproj'
proj = Xcodeproj::Project.new
app_target = proj.new_target(:application, 'App', :ios, '6.0')
header_ref = proj.main_group.new_file('./Class.h')
implm_ref = proj.main_group.new_file('./Class.m')
app_target.add_file_references([implm_ref])
proj.save_as('Test.xcodeproj')
Please let us know, opening an issue, which parts of the documentation you find confusing. For more karma use a pull request.
Related
I have a gem I want to add types to (either by submitting a PR or by forking to use just in my project), but the documentation does not give any more guidance other than to create an /rbi folder.
Thinking out loud, should it mirror the files in lib/ with added type signatures, or should it be one large file (per version?) like the signatures in sorbet-typed?
I don't know of any gems doing this yet, and the documentation doesn't mention it either.
I recently went through this process for one of my gems - pdf-reader. It was my first experience with sorbet (so I'm no expert), and I also noticed the lack of documentation for the specific use case of adding types to a gem.
I ended up generating the initial rbi file using parlour, which put them all into a single file: https://github.com/yob/pdf-reader/blob/480aa240a531cd6f97a46a29279f19025821e886/rbi/pdf-reader.rbi
Sorbet seems happy with that, so I haven't changed it.
I have a gem I want to add types to (either by submitting a PR or by forking to use just in my project), but the documentation does not give any more guidance other than to create an /rbi folder.
Thinking out loud, should it mirror the files in lib/ with added type signatures, or should it be one large file (per version?) like the signatures in sorbet-typed?
I don't know of any gems doing this yet, and the documentation doesn't mention it either.
I recently went through this process for one of my gems - pdf-reader. It was my first experience with sorbet (so I'm no expert), and I also noticed the lack of documentation for the specific use case of adding types to a gem.
I ended up generating the initial rbi file using parlour, which put them all into a single file: https://github.com/yob/pdf-reader/blob/480aa240a531cd6f97a46a29279f19025821e886/rbi/pdf-reader.rbi
Sorbet seems happy with that, so I haven't changed it.
When I run my Workspace on the simulator I get the message
"Class PFFile/ PFLogger is implemented in both (Path) and (Path). One of the two will be used. Which one is undefined."
I don't know how to solve this problem. I already tried cleaning and resetting.
objc[7398]: Class PFFile is implemented in both
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/PhotoFoundation.framework/PhotoFoundation (0x11fdaf1b8)
and
/Users/Sven/Library/Developer/CoreSimulator/Devices/20F88AC5-6C5F-4492-8324-9205B54FB32C/data/Containers/Bundle/Application/8DD1D026-2D96-49E1-A485-6FCBD9899005/FitTip.app/Frameworks/Parse.framework/Parse (0x108c27408).
One of the two will be used. Which one is undefined.
objc[7398]: Class PFLogger is implemented in both
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/PhotoFoundation.framework/PhotoFoundation (0x11fdaff28)
and
/Users/Sven/Library/Developer/CoreSimulator/Devices/20F88AC5-6C5F-4492-8324-9205B54FB32C/data/Containers/Bundle/Application/8DD1D026-2D96-49E1-A485-6FCBD9899005/FitTip.app/Frameworks/Parse.framework/Parse (0x108c279f8).
One of the two will be used. Which one is undefined.
Cause
You're seeing this error because both Parse and PhotoFoundation have files named PFFile and PFLogger. In Objective-C, your program cannot have two classes that share the same class name. This is part of the reason why Apple advocates using a three letter prefix for your own class names. Apple's own frameworks always use two letter prefixes, hence PhotoFoundation related classes have a PF prefix.
Unfortunately in this case, Parse also chose to use the PF prefix across all of the classes in the library that they built. In isolation this won't cause a problem, but when other frameworks come into the picture there's a risk of namespace collisions (which is exactly what's happening here).
Solution
You avoid a namespace collision by simply making sure you don't use the same names. In your case, you don't own either of these classes so it's not as straightforward. Luckily this issue was already reported on the Parse SDK GitHub page and the fix was implemented on the latest version of the Parse SDK (1.17.2). Parse's PFFile and PFLogger were renamed to PFFileObject and PFSystemLogger respectively.
You probably have an older version of the Parse SDK installed in your project. This can be verified by going into the root folder of the project and opening up Podfile.lock in any text editor. You can see what version of the library is currently installed by CocoaPods. Run pod update Parse and CocoaPods should update it to the latest version.
TL;DR pod update Parse. If that fails: pod repo update, pod install
Slightly different problem. Etrecheck pointed out this problem:
Class MDSPathFilter is implemented in both /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata (0x7fff9a7d1420)
and /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Support/mdbulkimport (0x10ad41948)
One of the two will be used. Which one is undefined.
I am not proficient in this stuff, but able to follow directions if anyone has any to share. They both look too important to poke at ...
After updating with Xcode 6.3, I found something strange things with my projects.
Below codes causes parse issue that says "Could not build module 'AgendaFramework'", the AgendaFramework is my custom embedded framework for ios8:
#import MyEmbededFramework;
The error marker looks like this:
The issues is raised during indexing not building. Whole building can be performed successfully without any error or warning. I can build, archive, run on device, deploy, submit to App Store.
However the error marker shows up when I edit the classes that belongs to the extension. The the extension(widget) explicitly linked to the embedded framework. (I know that I don't have to do it when I use #import statement.)
In this state, I could not receive any valid content assistant, very annoying.
After I replace the import statement with old style, the problem was disappeared:
#import <AgendaFramework/AgendaFramework.h>
I have several other projects that have very similar topology with the project which causes this issue, But they are okay. Only one project causes this issue. I compared every detail build settings, I could not find any clue.
I tried:
Delete derived data
Full Clean
Reboot
Any clues are welcomed. Thanks!
It looks like turning on:
Allow Non-modular Includes In Framework Modules solved this issue for me.
Hi this is due to the fact that file which you are making it public in framework header must be public also.
Sometimes this issue can be solved by adding the framework to the same folder as the .xcodeproj file, no subfolders or anything.
Credits to Jonny who points it out as a comment in the question.
Solution that worked for me: diligence in framework header file orientation to system style imports... like #import <CoreXLib/CoreThreads.h> the story:
In my case my framework that I built came from the combination of several code bases as it became apparent that I could reuse some of the general design patterns across that code easer via Framework vs the fragile Xcode project pathnames.
As I built my framework "CoreXLib", I reorganized it into the Cocoa Framework typical of Xcode. I changed my imports from:
#import "CoreTypeAliases.h" // project local style
to
#import <CoreXLib/CoreTypeAliases.h> // system or framework style
appropriately. Several projects that used the CoreXLib.framework which includes the public headers in the lego-folder worked... so I thought I was good to go...
Unfortunately some of the headers that were public did not get fully updated. The classes in the framework built just fine in the local style. All projects using it worked up to this point and then I ran into one that didn't... and the error noted by #jeeeyul
So after finding this thread and finding #kwz 's solution, and not having it do anything in my case, I decided to polish the code up while I was trying to figure this problem out. In the polishing, I found that some of the #imports did not get changed like they should have in the Xcode search and replaces. Time for some hand-jamming...
After fixing all of those references in all of my CoreXLib project headers (not just the public ones, self defense), I dove back into the problem... I took the newly complied CoreXLib.framework over to the errant project that embedded it... and the problem had vanished! I checked the Allow Non-modular Includes... in both the framework project and the project that linked the framework in and both were "No". Flipping both to "Yes" and to "No" made no difference in several tests. The only other change was the #import "..." to #import <CoreXLib/...> modifications.
So sometimes polishing the apple 🍎 knocks the bugs🐞🐞off...
set YES in Build Active Architecture Only in build settings.
It worked for me.
Today I solved this problem by those steps,:
Chose the schema "MyEmbededFramework"
Press [Command + B] to build
From the build phase panel, add "MyEmbededFramework.framework" to Link Binary With Libraries
Try to build your project, the problem may disappear now.
you can try this, it's work for me. delete DerivedData dir that about your project.step by step
Turn off module's in build settings. That may work
I am wondering what is the best way to include a demo project with a CocoaPod. In particular, I want this to a be a component that anyone can try using the pod try command.
I see two options:
option 1: embedded project in Examples/ with a Podfile
Here the Pod contains an embedded project, which uses a Podfile to reference the pod itself.
This is what is suggested by the directory structure produced via the pod lib create command, and by the CocoaPods documentation.
option 2: embedded project in Demo/ using pod as a resource
Here the Pod contains an embedded project, where the Xcode project file uses a relative path to refer directly to resources from the pod itself.
This is what I see in various examples in the wild, and it is what is working right now in a Pod I am authoring.
As CocoaPods is still in flux, I am wondering if one way is more "blessed" than the other. Is the documentation suggesting option 1 out of date? Or is the code supporting option 2 out of date? Will both work with pod try going forward?
Please, see as also this answer where demo project search heuristics are explained.
The best solution is to look through the def pick_demo_project(dir) routine in the try-plugin source https://github.com/CocoaPods/cocoapods-try/blob/master/lib/pod/command/try.rb#L133 to see the actual demo choosing options.