I'm successfully using the great Swift wrapper for sqlite from https://github.com/stephencelis/SQLite.swift in a Cocoa application.
But when I try to use the wrapper in a Command Line Tool project and follow the same detailed installation steps I get the following error:
Check dependencies
Unable to run command 'PBXCp SQLite.framework' - this target might
include its own product.
I checked the dependencies, but couldn't figure out how to solve this.
You can't link dynamic framework (a .framework) with your app in a Command Line Tool project. The reason is simple — a command line tool target builds a single binary file. This is unlike a regular Cocoa application, where the .app "file" is actually a folder containing .frameworks and other stuff inside.
So basically you'd have to build a static library instead (one that links with your app's binary during compilation) — except that as of Xcode 6.1 it's not possible yet with Swift.
So the only thing you can do — AFAIK — is add the SQLite.swift's source code directly into your own app target (so it compiles together). It's ugly, but works.
Related
Now that I found out that you can actually execute a swift program in command line by calling swift myScript.swift I was thinking about writing a few programs that I usually write in Python with Swift.
Although I can do that in another editor without trouble, I grew used to Xcode's completion (automatically fill existing class names, methods, constructor parameters, etc. that makes coding much easier). However, when I open a single Swift file in Xcode (without including it in a full project) with File > New... > File... Xcode doesn't do any completion.
Is there a special setup to do? Also, from a single open swift file, is there a way to run the script directly in a terminal from Xcode (and maybe use the debugger, etc.)?
As far as I know, Xcode is pretty useless for writing single independent swift scripts. I feel I'm missing something.
All the information I found was either about how to use the REPL in a terminal (and copy paste from a file written in any other text editor), or using Playgrounds (which are nice but incredibly slow when running simple algorithms that perform some nested loops or such), or of course making a small project, which feels way too much for some simple script writing.
Xcode's code completion and related tools work from knowledge of the compile-time and run-time environment of your code... that knowledge is supplied by the compiler. Xcode doesn't know what a compiler is doing with any given file unless Xcode is the one telling the compiler what to do with that file — i.e. the file is in an Xcode project, which specifies how to compile, or in a playground, which implicitly provides a certain compilation/runtime environment.
You can create an Xcode project for a Command Line Tool (using Swift, even). That'll tell Xcode how to compile it, and thus how to interpret it for code completion and whatnot. And hitting Run in Xcode will use the debugger, with command-line I/O in the Xcode window's debug area.
(And if you're looking for other ways besides playgrounds and projects for Xcode to work with Swift files... they do look at feature requests.)
I've created a Qt project using CMake as build system. I would like to include in the deployment phase, the necessary Qt frameworks
Qt3Support.framework/ QtNetwork.framework/ QtXml.framework/
QtCore.framework/ QtOpenGL.framework/
QtGui.framework/ QtSql.framework/
in order to be ready to distribute my program as standalone dmg.
This is usually done with macdeployqt command but it gives me a lot of errors like this:
ERROR: "strip: for architecture x86_64 object:
/Users/rs/build/myapp.app/Contents/Frameworks/QtXmlPatterns.framework/Versions/4/QtXmlPatterns
malformed object (unknown load command 5)
so I want to be able to do it directly in the deployment phase, is it possible?
I was using DeployQt4 and BundleUtilities for some time until I ran into a problem with it which wasn't easy to fix according to one of the authors.
I ended up writing a ruby script that does what BundleUtilities does barring that problem. My script has a limitation currently comparing to the BundleUtilities - it doesn't handle bundles with multiple executables. Writing the same functionality in cmake is beyond my degree of masochism (I managed to understand what BundleUtilities does and how but was appalled by the contraptions they had to use to organize data in memory).
The script itself is available here: https://github.com/artm/vision-ui-skeleton/blob/master/ruby/fixup/fixup.rb
It is used from cmake at the bottom of: https://github.com/artm/vision-ui-skeleton/blob/master/cmake/QArtmRelease.cmake
It works with ruby that comes with OSX 10.6.x and probably higher.
I've created an OpenGL application using the Command Line Tool project template.
Now the output project is obviously a unix executable.
My question is How can I convert this executable into a bundle .app?
Have I to add another target?
If you created a command line tool, it is just that, a command line tool. I don't know of any way to bundle it up into an application with ease.
If I were you, and you are going to start writing Mac OpenGL application, get set up with SFML. It greatly simplifies window creation, is cross platform and has a great community. Also, getting to the resource path in a mac .app bundle is a bit tricky and the templates they provide allow you to access any file with a call:
loadFile(resourcePath() + "filename.txt");
rather than having to keep track of everything. Plus, the whole resource path code is written in objective C which can be a pain for some C++ programmers.
The whole framework is pretty robust but maintains a simplistic style and its own namespace. Use what you want, don't use what you don't need. The latest version (still beta) 2.0, comes with Xcode templates. Just create a template and in build settings for your project, scroll to the bottom. You'll see SFML_LINK_DYLIBS_SUFFIX and it has a value of '-d'. Remove the '-d' and it should compile.
Then if you are distributing, add a copy files build phase and link the .dylib(s) that you used.
I just installed XCode 4 today (using Apple mac app store), and I created a new Mac OS application, and tried to switch to test mode,and build the test skeleton code it generated for me. It failed here:
In mytests.h:
#import <SenTestingKit/SenTestingKit.h>
The error is:
file://..mytests.h: error: Lexical or Preprocessor Issue: 'SenTestingKit/SenTestingKit.h' file not found
Now, when I use locate from the terminal to find SenTestingKit.h, I notice it exists under the /Developer-old/Library/Frameworks folder (which is what XCode 4 installer renamed my /Developer folder to). There is no new /Developer/Library/Frameworks. And I can't seem to find SenTestingKit.framework on my disk, other than the developer-old one.
What's up? It seems SenTestingKit.framework is not shipped with XCode 4.
Update:
Furthermore, When I copy my old SenTestingKit framework from XCode 3 into /Developer/Library/Frameworks, it sort of builds, but it doesn't work the way I would expect. The dummy test is designed to just fail, but when I "run test", I just get the normal cocoa app document window opening, and no indication that my test has failed (as I intend it to do).
This is pretty bad. I can't get a Unit test to FAIL. That's not the usual situation for me, you understand.
You may find that the reason for this is because you've installed Xcode 4 into a directory such as /Xcode 4.x/ or similar. The space is causing the problem because the -I paths are "Xcode" and "4.x/Library/Frameworks".
To fix this, what you need to do is select your test target, and under its build settings go and find the Framework Search Path, and put quotes around the two arguments, so you have:
"$(SDKROOT)/Developer/Library/Frameworks" and "$(DEVELOPER_LIBRARY_DIR)/Frameworks"
Then you default tests will compile, link and fail.
You will maybe need to import the framework into your project. Otherwise, the header file won't be recognize.
If you can't see the framework you're looking for, you can adjust the framework look paths in your project's build settings.
When you're building unit tests in the same project as you main code, make sure that XCode 4 didn't automatically connect you mytests.m file into the "Compile Sources" section of your main code.
For example, if you have two targets in our project:
MyProject
MyProjectTests
Check the Build Phases for MyProject to see if XCode added mytests.m into the "Compile Sources" accordion. This will cause your builds to fail because SenTest isn't included in the main project.
I have a custom framework that, following the advice in Apple's Framework Programming Guide >> Installing your framework I install in /Library/Frameworks. I do this by adding a Run Script build phase with the following script:
cp -R build/Debug/MyFramework.framework /Library/Frameworks
In my projects I then link against /Library/Frameworks/MyFramework and import it in my classes like so:
#import <MyFramework/MyFramework.h>
This works very well, except that I always see the following message in my debugger console:
Loading program into debugger…
sharedlibrary apply-load-rules all
warning: Unable to read symbols for "/Users/elisevanlooij/Library/Frameworks/MyFramework.framework/Versions/A/MyFramework" (file not found).
warning: Unable to read symbols from "MyFramework" (not yet mapped into memory).
Program loaded.
Apparently, the compiler first looks in /Users/elisevanlooij/Library/Frameworks, can't find MyFramework, then looks in /Library/Frameworks, does find MyFramework and continues on its merry way. So far this has been more of an annoyance than a real problem, but when runnning unit tests, gdb stops on the (file not found) and refuses to continue. I have solved the problem by adding an extra line to the Run Script Phase
cp -R build/Debug/MyFramework.framework ~/Library/Frameworks
but it feels like sello-taping something that shouldn't be broken in the first place. How can I fix this?
In the past months, I've learned a lot more about frameworks, so I'm rewriting this answer. Please note that I'm talking about installing a framework as part of the development workflow.
The preferred location for installing a public framework (i.e. a framework that will be used by more than one of your apps or bundles) is /Library/Frameworks[link text] because "frameworks in this location are discovered automatically by the compiler at compile time and the dynamic linker at runtime."[Framework Programming Guide]. The most elegant way to do this is in the Deployment section of the Build settings.
As you work on your framework, there are times when you do want to update the framework when you do a build, and times when you don't. For that reason, I change the Deployment settings only in the Release Configuration. So:
Double-click on the framework target to bring up the Target info window and switch to the Build tab.
Select Release in the Configuration selectbox.
Scroll down to the Deployment section and enter the following values:
Deployment Location = YES (click the checkbox)
Installation Build Products Location = /
Installation Directory = /Library/Frameworks
The Installation Build Products Location serves as the root of the installation. Its default value is some /tmp directory: if you don't change it to the system root, you'll never see your installed framework since it's hiding in the /tmp.
Now you can work on your framework as you like in the Debug configuration without upsetting your other projects and when you are ready to publish all you need to do is switch to Release and do a Build.
Xcode 4 Warning
Since switching to Xcode 4, I've experienced a number of problems with my custom framework. Mostly, they are linking warnings in GDB that do not really interfere with the usefulness of the framework, except when running the built-in unit-test. I have submitted a technical support ticket to Apple a week ago, and they are still looking into it. When I get a working solution I will update this answer since the question has proven quite popular (1 kViews and counting).
There's not much reason to put a framework into Library/Frameworks, and it's a lot of work: You'd need to either do it for the user in an Installer package, which is a tremendous hassle to create and maintain, or have installation code in your app (which could only install to ~/L/F, unless you expend the time and effort necessary to make your app capable of installing to /L/F with root powers).
Much more common is what Apple calls a “private framework”. You'll bundle this into your application bundle.
Even frameworks intended for general use by any applications (e.g., Sparkle, Growl) are, in practice, built to be used as private frameworks, simply because the “right” way of installing a single copy of the framework to Library/Frameworks is such a hassle.
The conventional way to do this is to have your framework project and its clients share a common build directory. Xcode will search for framework headers and link against framework binaries in the build folder first, before any other location. So an app project that compiles and links against the header will pick up the most-recently-built one, rather than whatever's installed.
You can then remove the cp -r and instead use the Install Location build setting to place your build product in the final location, using xcodebuild install DSTROOT=/ at the command line. But you'll only need to do this when you're finished, not every time you rebuild the framework.
Naturally, when you distribute your framework it should be installed in /Library/Frameworks; however it seems odd to me that you're doing that with the test/debug versions of your framework.
My first instinct would be to install test versions under ~/Library, as it just makes setting up your test and debug environment that much simpler. If possible, I would expect the debug/test framework to be located in the build tree of the version I'm testing, in which case it's installed as a Private Framework for testing purposes. That would make your life much simpler when it comes time to deal with multiple versions of your framework.
Ultimately, it doesn't matter where the framework is located as long as your application or test suite loads the correct version. Choose the location that makes testing/debugging/development easiest.