I am new to Xcode and MonoTouch, so please bear with me.
Is it possible to develop MonoTouch applications with Xcode instead of with MonoDevelop? I have read the MonoTouch Xcode tutorial but unfortunately the process described does not seem to work with the latest MonoTouch version (I get a "No SDK in directory" error, there is also no resource rules file in the root SDK directory). Finally, where am I supposed to put the directives to the MonoTouch compiler?
I have downloaded the trial version of MonoTouch.
Thanks in advance.
Its technically possible, but not in the supported MonoTouch workflow, so you'd be somewhat on your own. What you'd need to do is look at the output of a MonoTouch build with "-v -v -v" in the Extra Arguments field to see how we invoke the AOT compiler. You'll also need to look at the main.m generated by -keeptemp and adapt that in to your Xcode workflow. Lastly you would not be able to use the linker unless you maintained a parallel monotouch project which compiled and linked, and then you did a secondary build step to update your Xcode project.
Xcode does not support third-party plug-ins or environments.
Related
I am struggling with a problem while using Gitlab CI/CD.
I am using for my project two of my external frameworks. The project builds without errors but when running the pipeline I'm getting an error that says
This Copy Files build phase contains a reference to a missing file 'xxxxxx.framework'.
My project looks like bellow
This is en error I'm getting:
When I add framework file not the framework project then CI/CD will pass BUT then I'm getting the error when trying to archive project
Building for iOS, but the linked framework 'xxxxxx.framework' was built for iOS Simulator.
I don't know how to solve those problems to get everything work.
Thanks for any kind of help.
Regards
In case anyone is having this problem and is cloning a git repository that has submodules, be sure include the submodules when cloning.
Most probably what you will need out of these 2 options is to use the x.framework one. The error
Building for iOS, but the linked framework 'xxxxxx.framework' was built for iOS Simulator.
as it says, comes from the fact that the framework is only built for iOS Simulator.
Why is that?
Well, the iOS Simulator runs on x86_64 architecture (as OS X does), while iOS runs on arm architecture. So you'll have to compile the frameworks for both architectures. Fortunately, there is a way to do this, and basically what you need to achieve is to create a fat binary of the framework.
There is a script here from Sundeep Gupta https://gist.github.com/sundeepgupta/3ad9c6106e2cd9f51c68cf9f475191fa which can be used to compile the frameworks for both, iOS Simulator and iOS target architectures. There are also several different resources on the internet which explain what steps you need to make in order to create fat binaries.
I'd like to use the excellent stringencoders library in an iOS application. It's a fairly typical c library, with a configure script generated by autoconf and a makefile.
What I'd like to do is compile arm7 and i386 versions on Mac OSX and then use lipo to make a fat binary.
I'm having trouble figuring out how to persuade the build tools to create my platform-specific binaries. There's a few articles out there and even a few scripts but most of them are targeted at XCode 4.2 and don't work with 4.3.
It looks like it should be possible to create a fairly generic build script that can play nicely with configure and make but I'm at a loss as to where to even start.
Have you successfully done anything like this? I'd love some pointers!
BTW: 'import all the sourcecode into your project' is NOT a viable solution. That way lies madness.
Thanks.
I've ported a handful of open source C libraries to iOS (see iOS Ports). I've found the most reliable way to port a library is to build a new Xcode project with a build target for a static iOS Library. It is important to note that Apple will not allow your iOS Application to contain dynamic libraries if you plan to distribute your app on the iTunes App store, so you will be unable to use FAT libraries.
These are the steps I usually follow when porting libraries to iOS which usually built with the GNU Autotools:
Run ./configure with appropriate flags on OS X.
Verify that the library builds correctly on OS X using make.
Create a new Xcode project using the iOS Static Library template.
Add the config.h from the previous configure run to the Xcode project.
Read the automake file (Makefile.am), and add the referenced sources in the automaker targets to the Xcode target for the static library.
Copy the CPP flags (i.e. -DHAVE_CONFIG_H) from the automake file to the build settings in Xcode.
Compile in Xcode and start running down errors (usually by adding missing header include paths or missing source files).
The directory structure I usually use is the following:
project/
project/ported-project.xcodeproj
project/project-x.x.x.tar.gz
project/project-x.x.x
project/project -> project-x.x.x
I know this is not exactly what you asked for in your question, however it is rough outline of the steps I've used for years for porting libraries. The benefit of creating an actual Xcode to compile the ported library is that it makes it easier to integrate the library into multiple Xcode iOS applications.
If you need clarification or more detailed instructions, let me know and I"ll try to write up more extensive instructions and update my answer.
Is it plausible to add the source files (i.e. .c files) to your project directly?
Objective C is a superset of C so i am surprised that the code did not work directly out of the box in XCode 4. Are you missing out something there ? just suggesting
Generate your project files using gyp: http://code.google.com/p/gyp/
I use it to share libraries between win/osx/ios and linux (pi).
I'm getting the following error when including static libraries:
missing required architecture i386 in
file
This worked 30 seconds previously, and only failed when I upgraded to Xcode 3.2.3. I've used "file" command to check - and, yes, XCode is building completely the wrong architecture (armv6 + armv7 instead of i386).
This seems to be a major bug in latest Xcode, where Apple has re-written the build / compile / link settings. There's a note in the release notes saying very vaguely that they've "Changed it" because it used to be "confusing". This is not helpful.
The build settings for the library VERY clearly say:
"Valid architectures: i386"
There's no confusion here - Xcode is building something other than what the target says it should.
The question is: how do you un-break this? How do you force Xcode to do what it's supposed to? I've re-installed Xcode from scratch, cleaned everything, and manually inspected the build files. There's nothing wrong (and, of course, it worked perfectly in xcode 3.2.2)
After considerable research, I believe the answer is:
"this is now impossible - Apple has deliberately hard-coded XCode to ignore build settings"
However, I've come up with a script that automatically builds ALL platforms of a project (which you HAVE to do with static libraries - you don't have much choice now, because Apple has disabled Targets), and the script could easily be modified to do all targets, instead of all platforms:
Build fat static library (device + simulator) using Xcode and SDK 4+
Right click on your Target app under Targets and make sure that the Base SDK is set to iOS.
It is possible to build an iPhone application manually, without using xcodebuild nor an Xcode project?
The idea is to build the application using SCons without creating an Xcode project. I know there is the codesign command line tool, that I could use, but before I start reverse engineering the Xcode build process, I was wondering if anybody has experience with this or has done it before.
Yes, It's possible to write a makefile using gcc. You're going to want to set your GCC to use frameworks from /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.1.2.sdk/ (frameworks being in system/library/frameworks, and usr/lib).
As far as specifics, I think you're going to have to work that out yourself - but pay careful consideration to the architecture options in GCC and you should have something working quickly.
Xcode just wraps gcc/g++ and ld (and yes, codesign). Take a look at any Xcode project build output and you'll see what commands it uses. I believe the key to building an iphone app is the -arch parameter.
I have searched for hours however I still have no clue what is wrong with my configuration.
My project uses a self-written libray (myLib). This library is compiled to work only for simulator and it works perfectly there.
What do have to change so it compiles for my iPhone Device as well?
This is my current warning:
ld: warning: in /.../myLib.a, file is not of required architecture
This is my configuration (of myLib.a)
I found a lot of articles explaining the reason for this error however I could not find a solution:
The simulator runs on an x86
architecture, while the device uses an
ARM architecture.
What do I have to change to get my library working on my iPhone?
Thanks
Edit:
What I did so far:
Cleaned both projects
Set library to 'Device' (3.1)
Built the library
Dragged the .a file of my library into my application
Result:
This works in simulator but setting the active sdk to device still raises a file is not of required architecture error.
I also tried mahboudz ( thanks for your support) link.
It explains howto built the project using a shell script.
However XCode keeps complaining that the library file is of the wrong architecture and the build fails.
This has to be a really stupid beginners mistake.
You need to add both .a files,the one built for the device (build/$config-iphoneos)and the one built for the sim (build/$config-iphonesimulator) to the new project. Make sure you name them differently before dropping them in. This is how admob and similar offering ship their static libs.
You need to compile your library for Intel so the Simulator can use it (which I gather you have done already), and then compile it for ARM, so it can run on the iPhone. Then you have to merge the two libraries. There are different ways to accomplish that, or make it more automatic.
Here are some links to help you:
http://blog.stormyprods.com/2008/11/using-static-libraries-with-iphone-sdk.html
http://www.clintharris.net/2009/iphone-app-shared-libraries/
I've met the same problem too. But seems you don't need to drag two .a files into the app project to solve this problem. This is what I did:
Drag the static library project into app project's framework group
"Get Info" for the target in app project
Set the direct dependency of static library
Make clean all unnecessary builds(for example the simulator build) in the static library project
Build in the app project