I'm following this tutorial on using OpenGL in Swift. It apparently depends on some GitHub Repo for GLFW and uses a Package.swift file to build it into your executable. Sadly, while running the instructed build command swift build -Xcc -I/usr/local/include -Xlinker -L/usr/local/lib I get the following error:
error: Empty manifest file is not supported anymore. Use swift package init to autogenerate.
When I run the suggested init command, I get:
error: a manifest file already exists in this directory
What should I do?
That tutorial is written for Swift version 2, and it’s been outdated for some time. The only reason you need the library in that repository is because it defines some OpenGL function loaders necessary to make your program link properly. I currently use a patched version of that SGLOpenGL library that I hacked to make it compile under Swift 3. I believe this is the only way currently to use OpenGL with Swift. You will have to correct the Swift UnsafePointers and rewrite the function parameter lists to use (or remove) named arguments, among other things, as Swift 3 was a source-breaking release. The compiler will generally tell you what you have to do, it’s just a lot of tedious work.
Note that you don’t need any of Turnbull’s other libraries to use OpenGL with Swift. You can easily (“easily”) write your own implementations of the Math functions for the quaternions, vectors, matrices, camera frusta, etc. Google is your friend, as most of these routines are well-studied problems in computer graphics, and there is a great deal of pseudocode and C++ implementations on the web to help you get started.
The Image PNG library is non-trivial to replace, but luckily there already exists a native Swift PNG decoder MaxPNG† designed to work with graphics frameworks.
Good luck!!!
† (Disclosure, I am the author of MaxPNG; I wrote it because I was in the exact same position as you a few months ago.)
Related
Xcode supports custom Build Rules for different source files. I am particularly interested in Swift build rule.
What should be correct script to compile the sources and what to specify in Output Files?
Please, answer the question if you did have experience with that.
Swift files are compiled with swiftc implicitly, as well as Obj-C with clang. Afaik it's not possible to substitute that call with a Build Rule, as you also would need to pass tons of arguments for the optimizer, libraries for linker e.t.c. The output of source code compilation is object files (*.o), which are then linked together to form a resulting binary.
You can read about this process here and here.
In this tutorial on how to use CocoaPods I am having trouble understanding the following paragraph:
Unlike Objective-C, the standard Swift runtime libraries aren’t
included in iOS! This means your framework must include the necessary
Swift runtime libraries. As a consequence, pods written in Swift must
be created as dynamic frameworks. If Apple allowed Swift static
libraries, it would cause duplicate symbols across different libraries
that use the same standard runtime dependencies.
Here are my questions:
What exactly are the "standard Swift Runtime Libraries"? Is the Swift Standard Library one such standard swift run time library, would a framework I write in swift be considered a swift run time library?
What exactly does "Swift runtime libraries are not included in iOS" mean? I guess I am having trouble inferring what "iOS" refers too.
Any additional insight, links, resources or explanations regarding this paragraph would be greatly appreciated!
Edit:
After reading the runtime library wiki article I am no longer confused about Q1. The following paragraph clarified this for me:
The concept of a runtime library should not be confused with an
ordinary program library like that created by an application
programmer or delivered by a third party, nor with a dynamic library,
meaning a program library linked at run time. For example, the C
programming language requires only a minimal runtime library (commonly
called crt0), but defines a large standard library (called C standard
library) that has to be provided by each implementation.
However I am still confused about Q2.
Objective C has a stable (unchanging) runtime library, so it makes sense for there to be one shared copy of the library, provided by the OS (macOS/iOS), available to all applications that need it. In contrast Swift is a rapidly evolving language, which means that its runtime library undergoes vast changes between versions. Because of this, Xcode bundles in a copy of the Swift runtime library as part of each app, to ensure that a copy of the correct version (the version the app uses) of the runtime library is available to the app.
Swift Standard Library vs Swift Run Time Library
[Swift Standard Library]
Swift Run Time Library is a part of Swift Standard Library
Before iOS v12.2 there were not ABI[About] stability on iOS level, that is why you could see a lot of frameworks(Swift standard library[About]) inside each built target
Also you are able to adjust it via Always Embed Swift Standard Libraries(ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES) for targets before iOS v12.2
I'm exploring Swift with Xcode-6 and so far so good although I think the new collections need a little bit of work as I've managed to break the compiler a few times.
Problem is I'm now stuck trying to create the framework package to then use in another project. The project builds without issue and all tests pass successfully. When I go to create Archive (which I assume is what is required) I receive the error:
:0: error: underlying Objective-C module 'Sample' not found
Now I assume this has something to do with the contents of my Sample.h which tells me
// In this header, you should import all the public headers of your framework using statements like #import <Sample/PublicHeader.h>
which is fine except I have only used swift enums, structs and classes for this framework so therefore no .h files exist.
Can anyone shed some light on this one as I can't find any documentation available yet?
EDIT (7/27/2018)
The information in the answer below may no longer be accurate. Your mileage may vary.
I sat down with an engineer and asked this exact question. This was their response:
Xcode 6 does not support building distributable Swift frameworks at this time and that Apple likely won't build this functionality into Xcode until its advantageous for them to do so. Right now, Frameworks are meant to be embedded in your app's project, rather than distributed. If you watch any of the session videos or see the sample projects, this is always the arrangement. Another reason is that Swift is very new and likely to change. Thus your Swift-based framework is not guaranteed to work on the platform you originally built it on.
Slight Update
The engineer mentioned that it's not impossible to make a framework for distribution, just that it's not supported.
I was able to get past the error by going to the target for the framework and on the Build Phases tab under Headers, remove the MyFramework.h file
However I was getting the "Underlying Objective-C module not found" error when I was using a framework to share code between a containing app and an app extension, both of which were pure Swift.
Assuming you are creating a truly pure Swift module, you must disable the Objective-C Compatibility Header and any generated interface headers so the compiler doesn't go off assuming it can find an Objective-C module for the framework.
Do Not remove your public framework header. You'll get a module-map warning at link time if you do.
You might find this useful: Creation of pure swift module
In short: it's possible to make static framework, but there is one issue: it doesn't work in end user' project if "ProjectName-Swift.h" header included.
But, it works fine if you use only swift.
I think it's a bug in XCode 6, or that Apple does not allow archiving the Framework from XCode while in beta.
If you compile to profile XCode generates the framework correctly. (See the Release folder created in DerivedData)
I'm interested in Swift programming, but I'd prefer not to use Xcode as it is too bloated for my practical use.
I know this is possible to do with Objective-C with something like
clang -fobjc-arc main.m myclass.m -o prog1
where the different .m files are just listed out, but I don't know how to do this with Swift. I can use the basic Swift command-line tool, like swift MyProgram.swift which just produces a binary called MyProgram.
As far as I can tell, this command won't let you compile multiple .swift files together.
Ideally, a system like makefiles for C++ would be ideal. Is there any way to do this with Swift currently from the command line?
While you can use swiftc, the recommended way after Swift 2.1 is open-sourced is to use swift build as described at Swift Package Manager documentation.
An important note from that document:
Please note, that the 2.2 release snapshot does not come with
swift-build-tool, either download the development snapshot or build
your own copy of swift-llbuild.
By developer snapshot they mean a developer snapshot installer from the official package or anything that's newer than Swift 2.2 at the moment.
I recommend swift build for convenience, if however you want to do it by hand still, then run swift build -v and you will see the commands that are run by swift build so you can construct your own command lines.
Is it possible to link a C# library compiled using monotouch with an objective-C front end in a single application, or does the app have to be all or nothing?
It is possible but you aren't going to get any help from the MonoTouch tooling and you can't get away from the fact that you still have to have the Mono runtime to execute your C# code.
In order to provide the Mono runtime to the Objective-C app, the runtime will have to be embedded into the app. The MonoTouch site has some docs on how to do this here and you can find more technical details about embedding Mono into your application here.
MonoTouch, when compiling your C# code, produces .m and .s files that are used by Objective-C to call that code. These files will need to be included in the consuming Objective-C project but MonoTouch cleans up those files after they've been used. In order to keep mtouch, the MonoTouch compiler, from deleting the .m and .s files, use the --keeptemp option when invoking the compiler. You can find a good sample Makefile here to help you figure out how to call mtouch correctly from the command line.
Finally, you will need the full version of MonoTouch in order to do this. The trial version will not generate the .s files.