I have RestClientLibrary and UserFunctionsLibrary
UserFunctionsLibrary needs RestClientLibrary in order to function.
When I compile these down to libRestClientLibrary.a and libUserFunctionsLibrary.a how will they be able to interact with each other?
In Xcode currently I have set the User header search paths to find the .h files and I have linked the UserFunctionsLibrary with the RestClientLibrary binary. However, when distributed other users of these libraries may have different set ups and such. I can't see that it will work.
Thanks for any insight you can give me.
Those .a files are just library files. They will need to be linked together to actually be used. The linker will handle resolving all the symbols from RestClientLibrary into UserFunctionsLibrary.
As far as other users, they will have to configure their system in a way such that both libraries are passed to the linker.
Related
What are the different possibilities when this error can occur?
What are the things one should look out for, in order to get rid of this?
What if XYZ is an static library directly added to project?
It means you are trying to link to a library which is not found by the system. In your case that appears to be a simple static library. You should check the following:
Look for the corresponding item in red among your project files, with special attention to the Frameworks group (that's where people normally put libraries). If you find one, fix the path or just remove and re-add the library manually.
Repeat this in the Link Binary with Libraries entry under the Build Phases tab in the project/target settings.
Check the Library Search Paths entry in the Build Settings tab in project/target settings. Make sure the path to your libXYZ.a file is listed there.
I have created a Mac app that can generate iphone ebook app project source codes.
I know I can using xcodebuild to build the project to get the release binary file.
Is it possible to hide the source codes of .m files(maybe store in memory) and build project using xcodebuild?
Welcome any comment
Thanks
Marc
It sounds to me like you are attempting to generate source code for others to use, but then hide it so they cannot see whats been generated. Basically not possible. You could generate obfuscated code which would make it harder to read, but not impossible.
Realistically what you are trying to do is generate template code for others to use. If you don't want them to be able to see it, then you presumably don't want them modifying it. The easiest answer is to simple not do it. Instead, create a compile static framework containing your code and IP, and then only generate templates which makes calls to your framework. Thus your code is protected.
Your question lives on the edge of being programming related, and I'm not exactly sure what problem you're trying to solve.
However, you can create a RAM disk, store your project there and run xcodebuild against that. Just be aware that you're not really protecting the .m files so much as limiting how long they are easily visible.
In Xcode there are many frameworks (like mkmapkit.framework).
This framework contains only .h (header) files. Where can I find the corresponding .m (implementation) files.
The implementation files are not distributed with Xcode. Apple keeps them proprietary.
The framework classes are available as binary library files (.dylib, .a etc. for example). So .m which are implementation source files are not available. Header .h must be available as without header files compiling is not possible.
The only way to see the implementation is to decompile the frameworks static library with tools like those described in this question:
Decompiling Objective-C libraries
Since the frameworks you are probably interested in will generally have symbols stripped, it will be a bit of a task understanding what is going on but you can glean some things from tools like these.
You can find them inside Apple's internal source code repositories. If you work at Apple on an appropriate team, you can check them out. If you don't, then you're out of luck.
I was always wondering what's up with those Targets? What is it all about? What's the point of that? I never had to fiddle around with them, but obviously I can. Why should I want that, and what can I do with them? What's their purpose?
Each project can build multiple executables or libraries or call out to a makefile or shell script to build "stuff". Each one of these is a Target.
One iPhone project I have includes a separate target for each static library in my home grown SDK and a shell script target to build the Doxygen docs. Another project includes two targets, one for the app as used by general users, one for an administration & management edition.
In the first example, I need to build each library then link all the static libraries into an SDK test application, so my SDK Test App depends on all the library targets (but not the docs, since I don't need to constantly regen them.)
In the second example, the management and the general versions of the app share a considerable amount of code and resources. When I change one, I want to change them both.
The target is something like a "blueprint". It includes rules that tell the compiler what to do, which sources should be compiled, which files should be copied into the application bundle, which libraries should be linked.
If you want to make a Free-Version of your app one way to do so is to add a new target.
Of course you could just duplicate the whole project but then you had to keep those in sync if you change some code. Using a different targets makes this a lot easier.
I have some utility functions like:
void myVibratePhone()
{
AudioServicesPlaySystemSound (kSystemSoundID_Vibrate) ;
}
that I'd like to use across all my projects.
In C, I'd give each project the header file, and link in the .OBJ file (or perhaps create a library).
What is the Apple-approved recommended way to share code (cocoa and C primarily) among my apps? Would I need a framework for this? How would I go about creating one?
Also, since I'm using subversion for version control, if I use a framework, do I place the version of the framework that the app is using in the subversion repository for the project so that anyone who checks it out can build it straight away or make it a requirement that people check out a project + check out the utility functions also for a successful build of any project?
I don't plan on putting anything on the App Store at this time, but I don't want to do anything that will cause apple to not accept an app in any case.
I found this writeup about xcode 3.0 (I'm using Xcode 3.2.1):
How do I create a bundle of reusable code in Xcode?
I followed it, but am having one issue:
1) trouble finding my library .h file in the main project: I've tried both hardcoding it in the main projects .h file
#import "file://localhost/Users/piesia/Documents/My Utilities/MyUtilities.h"
as well as:
#import "/Users/piesia/Documents/My Utilities/MyUtilities.h"
and
#import "~/Documents/My Utilities/MyUtilities.h"
I've also tried updating Header search paths in the Project Build settings:
"/Users/piesia/Documents/My Utilities/**"
when using #import
After a lot of trying (and replacing %20 with space), I was only able to get the variants
#import "/Users/piesia/Documents/My Utilities/MyUtilities.h"
and
#import "../../My Utilities/MyUtilities.h"
but I'd prefer not to hard code the path if I can figure out a better way.
So, in closing, 1) is the writeup that I'm following the recommended way to do shared code in Xcode 2) is it recommended that I keep the shared files in a separate subversion repository from the main program and link and include it in as I'm doing now and 3) do you know what I'm doing wrong in my attempts at loading the shared header file? Would anything that I'm doing or not doing with shared code hurt my chances of getting approval if I ever decided to submit it to the App Store?
I agree with creating a static library to share the code.
To add the headers to the project you need to set the "User Header Search Paths" to the location of the .h files.
You then import the headers using something similar to:
#import "YourHeader.h"
You shouldn't need any additional path information in the import if the header search path is set correctly.
Oh this one is a bugger! - I think unfortunately the easiest way is to hardcode.
My team has dozens of reusable components in our products, many of them shared between Mac and iPhone. My experience in this is that most of the time it's much easier to just include the source code rather than to create a separate static library. The separate project for the library adds a lot of complexity and seldom provides much value. Here is how I usually approach it:
In subversion we have a directory tree like this:
/common
/Component1
/Component2
/Project1
/Project2
...
In Project1.xcodeproj, we just drag in "Existing files" from common into the tree (don't copy). Doing it this way avoids lots of overhead in managing another project. This does mean that changes to the common tree can break any of the projects. That means you need to recompile everything before committing (we use a top-level build script to check that you didn't break anything). The advantage of the static library is that you can stage this by upgrading the library for each project when it's ready. On the other hand, it means that you have to rev the library often and manage syncing it around. We've found that just sharing the code directly typically is much more effective.