I'm a beginner programmer using Xcode, and I'm trying to make a static library so that I don't have to copy files over every time I write a new program. Problem is, I could not find a satisfactory explanation of how to do this -- I've tried a few tutorials and I'm sure I've skipped some steps. So:
I have an Xcode project with my class files. It's got a class to deal with large numbers called Large -- Large.h and Large.m. I chose to make it a static library, and I built it.
Then, I made a new project and followed this. I tried to #import "Large.h", but Xcode still wouldn't recognize the class Large as it does in my projects that have a copy of the source files themselves. I'm probably doing a ton of things wrong... What do I do? Thanks a lot!
I wrote a tutorial some times ago... Hope this will help you:
http://www.eosgarden.com/en/articles/xcode-static-libraries/
Related
I have a framework building where it combines both Objective-C and Swift. My issue is that some of the Objective-C code within the framework needs to use some of the Swift classes in the framework. In order to do this, I do:
#import "FrameworkName-Swift.h"
in my Objective-C code in the framework. And here the first problem arises. The -Swift.h header is not located by Xcode this way. Digging around in the Derived Data, it turns out the -Swift.h file is located in the Framework/Headers folder, which in of itself seems odd. Should the -Swift.h file really be an exposed header for the framework? The -Swift.h file is an intermediary .h file, right?
To work around this issue of not locating the -Swift.h, I tried:
#import <FrameworkName/FrameworkName-Swift.h>
BUT, while now locating the -Swift.h file, this causes a severe and compilation-fatal rash of cyclic dependencies in Xcode, with messages like:
Cyclic dependency in module 'FrameworkName'
Could not build module 'UIKit'
Here's what those look like in-situ:
Thoughts?
I have an incomplete answer to this, which is more of a partial explanation and a workaround that works for me. Here's what I think is causing the issue.
While Apple let's you call Swift code that is in the framework, from your Objective-C in the framework, if the same Objective-C class also needs to be used from Swift you run into an include/import cycle. Here's the situation I have.
Call my Objective-C class Objc with files Objc.m and Objc.h
Now, since Objc has to use Swift code it needs an import something like this:
#import <FrameworkName/FrameworkName-Swift.h>
which in my case goes in the Objc.m file.
And since the Swift code needs to use the Objc class, you need the following in the Framework umbrella .h file (the umbrella .h file is named FrameworkName.h):
#import <FrameworkName/Objc.h>
Now, if you take a look at the FrameworkName-Swift.h file that is generated by Xcode (Xcode 7.0.1 in my case), you find that it has an import of #import <FrameworkName/FrameworkName.h>, which forms a cycle back to Objc.m.
My workaround for this was no more than a situation specific hack. It turns out that in my case Objc.m didn't critically need the Swift code. It just made the code look nicer and better engineered. So, with a comment and a couple of extra lines of (Objective-C) code in Objc.m, I worked around my issue.
Very insidiously, Xcode 7 (at least) is really resistant to getting out of this issue once you are in it. That is, when you get this cyclic dependency error, it can be very difficult to have Xcode stop telling you you have it, even if you have taken the cyclic dependency out of the code. I tried many things including removing all of the Derived Data files/folders, quitting Xcode, and restarting my Mac, and found nothing that worked consistently to have Xcode stop believing it had a cyclic dependency even though I'd fixed the issue.
This resulted in the more difficult fix. I had to effectively rebuild my Framework from scratch, every step along the way building and saving to my version control system so I'd be darn sure I could recover if Xcode started being convinced I had one of these cyclic dependencies. Makes me have even less faith in Xcode. :(.
Second fix: A workaround (10/9/15)
I've found a fix that works in some other cases:
1) Clean/remove your Xcode Derived Data, including the ModuleCache
2) Build a known working copy of your Xcode project (in my case, I had a revision before I started adding the framework)
3) Now, go back to your Xcode project with the framework included and attempt a build. For me, this now works.
This is strictly a work-around, and resolves a cyclic dependency issue that appears in somewhat different framework conditions for me than I described in the present question. I'm talking to Apple engineer right now about this issue, so will see if I can get a better fix. I'd rather not have to apply this workaround.
"Final Solution": Namespace pollution (10/22/15)
I have figured out what was going on!! It was a case of include file name space pollution. I had an Objective-C class named "Assert" (note the upper case "A"), with files Assert.h and Assert.m. I have been using this Objective-C class (part of my internal debugging) for quite a while. At least a year if not more, to no apparent problem with Xcode. Now, when I started using it in conjunction with a Cocoa Touch Framework of my own construction, a problem came up. It turns out that if I cleaned the Derived Data first, that the /usr/include/assert.h file was being picked up, and not my own Assert.h
Really odd.
And, if the Derived Data was not cleaned and I'd built a non-framework version of my project first (for the specific platform, e.g., for my iPhone if I was building for that), then my own Assert.h would get picked up.
My fix was pretty simple-- took about 10 minutes. I changed the name of my file/class to SMAssert with files SMAssert.h/.m. And then changed the references to the file in the various places that imported it. Voila!
I am trying to add GLM to a project in Xcode 4, but I cannot get it to compile. I have added the glm files to my project through the add files dialog.
I get a lexical/preprocessor issue and Xcode cannot find the file <cmath>.
I am not sure what I need to tweak to get this to build.
I have seen How do I add OpenGL Mathematics (GLM) to Xcode 4? already.
All you need to do is add the files to the project and #import "glm.hpp" (for Objective-C++; for simple C++ it should just be #include "glm.hpp").
A couple things to be careful of:
The OpenGL Mathematics library, when you download it, comes with a bunch of stuff you don't need (test code, extraneous utilities). Adding these to your project will result in compile errors which I could not get rid of. The only directory you need is the glm/ directory; you can delete the test/, util/, doc/, and bench/ directories. If you were trying to follow "How do I add OpenGL Mathematics (GLM) to Xcode 4?" and were still having problems, this may be the thing which was tripping you up.
The OpenGL Mathematics documentation tells you to include the or files. In Xcode 4, you should include them like "glm.hpp" or "*.hpp". Xcode will find the files no matter where in the project they are. Supposedly you can add a user-defined build setting "USE_HEADERMAP" and set it to "NO" to disable this, but I didn't have any luck with that.
And, just in case, note that your code files using the OpenGL Mathematics library must be Objective C++ files (ending in ".mm"), not the default/plain Objective C files (ending in ".m"). It is very much a C++ library after all... :-)
I hope that help. I was just working through this myself, and I haven't had the chance to really push this (e.g. I've basically just added a mat4 object or two and made sure things still compiled), but it seems to be working.
I ran into the same problem and I solved it remaning my ViewController.m to ViewController.mm. Change the extension to .mm tells XCode that the file may contain C++ code inside. The article Write Object-C Code explains this in the Classes and Objects section.
I am currently learning Objective C programming using Xcode. I am wondering how to have multiple main programs, i.e. source members with main method in it, in a single project? It is a bit inconvienient to put just one in each project, as I would have to create tons of them through my learning process. Or is there any better way to do it? All I want is to place multiple independent executable programs in a single project, though I only need to run on each time. Thanks a lot.
This is much more trouble than it's worth. Just create tiny test projects. I've got a huge directory of them that I throw away from time to time. I also constantly re-create a project called "Test" for building little projects.
For really, really tiny things, I do sometimes create a simple test.m file that has its own main and compile it by hand:
gcc -framework Foundation -o test test.m
But in that case I don't bother with Xcode.
EDIT You of course could replace gcc above with clang. For projects so small that I'm doing this, it hasn't been worth changing my muscle memory....
Each target can have a maximum of one main() method. So you need to create a different target for each program and put each main() into a different source file. Each source file with a main() in it can be comiled into only one target.
If your mini-projects are simple enough you could also put it all in one project, creating classes/methods for each subject that you would otherwise have created a new project for.
It could be a class "Experiments" or "Learning" with methods like "experimentWithSomeStuff" or "testSomething". You could instantiate this class in main and call just the method you are working on at the moment.
I did this when I learned ObjC-Basics and it worked fine for me.
This way you can quickly check your "older" experiments to refresh how something works.
I found out that you can make many applications, lets called them that, in the same Xcode project by creating new targets, and to test them individually, you just need to go to Product-> Manage schemes and choose the target you want to build and run.
I guess then Xcode runs the main associated to that target.
I'm looking for a free Visual Studio feature, extension or macro. that can help with the following situation.
When I prototype I tend to keep all my classes in one file (bad practice I know, but yeah it a prototype). Then comes the point the where the files is too hard to navigate. So I breakout the classes into separate files inside the project, the folder structure reflecting the namespaces.
To achieve the is;-
1. Add new Folder
2. Add new Class
3. Name class
4. Cut and paste corresponding section into new class file.
For me, Steps 2 through 4 are prime fodder for a new Menu entries.
Cut Class as New Class File
Cut as New Partial Class File.
I've seen this feature in C# but not VB.net.
So does know any how to achieve this for VB.net?
Here's a macro that does what you want in C#... looking at the code it's probably fairly straight forward to modify it to work in VB...
http://plisky.net/main/macros/documentation
Also, I'm pretty sure all the commercial refactoring tools (Resharper, CodeRush, etc.) support this...
Resharper can do this using Move Type to Another File or Namespace
I just stumbled across this and can point you to an updated version of the macro that scrappy kindly linked. Its at http://plisky.net/main/plisy.net-visual-studio-productivity-macros.
If you still want it and wish to test it for VB I can happily make the changes to support VB.net but as I don't use VB I'd need a tester :) As its a while since this post you probably have something working already though.
Just stumbled into something strange with Xcode 4 and Cocoa frameworks. I've a meta-framework that is essentially a .h file with constants needed by a number of other frameworks I've created. I'm capable of creating and building the framework but every time I try to include it in a project Xcode would throw a hissy fit during the build phase, saying it couldn't find the framework, even though the .framework folder was there and the .h file was set to be publicly visible.
After many a hours of running in circles I decided to throw in a .m and corresponding .h files, just so I could have something binary in there and now Xcode is happy as Larry.
Can someone explain this behaviour to me? Why do I need a useless executable to make Xcode see my framework?
The hissy fit is presumably coming from the linker. (Always post your error messages! Guessing isn’t that much fun.) As far as the linker is concerned, the binary is the framework. If you just want the header, you can include the framework in your search paths and #include the header without linking to the framework.