I am a game developer. I have developed a game using box2d which is in Final Phase. To structure the code when i attempt to make code refactoring i am receiving this error alert http://screencast.com/t/ir1nCvnx . But when i attempt to make code refactoring for another project which is not using .mm suffix means i can make it out. The thing i want to know is can we do code refactoring for the code using c++ concepts. If not what is other way to do code refactoring.
I thought because Xcode depended on the clang front end for all of its
code coverage features, that it would eventually be able to refactor
C++. As I understood it, it didn't refactor C++ in the past because
clang's C++ support was still insufficient.
But clang is a very good C++ compiler now. Yet Xcode still balks at
even renaming symbols (the only refactoring I've ever needed).
So, till now, you can not refactor your C++ code and hope you will get it with new release of clang / LLVM / XCode.
Related
This is a variant of the old "dyld: Library not loaded: #rpath/libswiftCore.dylib" problem. I'm pretty sure I know what the issue is, but I don't have any ideas on how to fix it.
I'll reference the project I'm working on, so I don't clutter the question with huge blocks of code.
The project generates a dylib that can be thrown into another project, and abstract a huge block of coding for developers (a communication layer of a client/server system).
I want the framework to be as simple as possible to to use; even if that means making it a big fat pig. I just want people to be able to toss it into their project (Swift or ObjC), and not have to worry about playing around with different variants for things like simulators and devices.
I use a variant of the old Wenderlich script to lipo the executables for x86 and ARM together.
Note the commented-out section. There be draggones.
Works great. In Swift.
Objective-C, not so great. That's because of the various Swift frameworks that need to be carried into the Objective-C program.
I switched on the embed frameworks setting, and the target dutifully gives me all my frameworks.
The problem is that each architecture has frameworks for ONLY that architecture. They aren't "fat" frameworks, so my hand-built "fat" framework really is kinda skinny, because it will only work on certain architectures.
My question is whether or not there's a way to ensure that the Swift frameworks I embed can be made "fat," or if I just have to give up, and package different variants of the framework for Objective-C programmers.
Any ideas?
I'm giving up on this sucker.
You cain't git thar f'm here.
This library will be Swift-only.
I need to use a framework for and old obj-c project. The problem is, before I used to compile again and again code in a binary and then lipo it. Now with the swift architecture, it generate some Apple specific files, and of course, it is too hard for (or unintuitive to) Xcode to generate the framework for the architecture I want.
I googled how to do it, but to my surprise, I just found old post who talk about the old way with the standard binary output.
My question is how to simply generate a swift framework for the wanted arch. For the moment the only solution to my problem is to compile a framework for the simulator and another one for the phone. But I have no idea how to fat it. Or if it is the right approach.
I can't believe there is no way to ask Xcode to build it. But since we are talking about Xcode...
One of the project we are currently working on uses a static objective-c library created by an ex employee.
The problem we have is that the library was built for arm7 which has 32 bit architecture. Is there a way to recompile for new architecture. It seems like a long shot though.
___Edited I don't have the source code.
Do you have the source code and Xcode project? If so, the answer is yes. As mah says, you may have to refactor the project for the latest IDE.
If you don't have the source code then the answer is a resounding "NO!" Compiling means converting source code into machine code. No source code = nothing to compile. You might be able to analyze the machine code and reverse-engineer it, but that's a horrific amount of work.
If I create an Xcode project with the iOS Single View Application template and choose Swift for the language, will the compiler exclude from the release build (binary) functions that never get called?
I'm wondering because I want to include a third-party library that has a lot of superfluous classes & functions, and I want to keep my app small & fast.
While I agree with comments, it is unlikely to impact performance in any significant way even if it was included...
Xcode 6 uses Apple LLVM Compiler Version 6.1, depending on how closely related it is to LLVM Developer Group's version the optimization feature is available http://llvm.org/docs/Passes.html with options such as -dce: Dead Code Elimination, -adce: Aggressive Dead Code Elimination.
One way to know for sure what is included is checking the assembly output using -emit-assembly option in the swift compiler and review the output, or opening the binary in a disassembler such as Hopper ( http://www.hopperapp.com/download.html )
i have this problem for a while now. I have iPhone project which was built with non ARC. And now somehow i need to add another smaller project to it, but that project was built with ARC. I have tried to copy files one by one, but ass soon as i was done, i got lots of ARC errors and some with Security.framework... Can someone help me? Or give me some ideas how should i proceed?
I have tried this but it didnt solvet issius with ARC...
ARC is done at compile time. ARC-enabled source code files need to be compiled with ARC, non-ARC source files need to be compiled without. It is a s simple as that. ARC is nothing but syntactic sugar injected by the compiler.
I have had this problem with some third parties not entirely migrated to ARC. Just create a static library around these files.
You could also try to change the per-file compiler options (see this question: How to disable ARC for a single file in Xcode 5?), but I would recommend against it since it will just become a maintenance burden in the end.
And of course, if it is your source code and not some third party: Migrate it to ARC. It is worth it.