Now, I've had an extremely hard time finding information about OpenGL headers and extensions and how to access the latest features. OpenGL.org doesn't touch upon any of this, neither does Mesa (updated 2006!) or anyone - but I can't think I am the only one wanting to understand this.
I am developing on Archlinux with Nvidia drivers - supporting 4.2 - which apparently doesn't come with the OpenGL headers (not the repository ones anyway). This is where the problems and confusion started. I read that I should use the Mesa3D headers - currently supporting OpenGL 3.0. This is what I have installed now.
Now, I read somewhere that the core OpenGL 4.2 header - gl.h - only exposes the features from OpenGL 1.2. The rest (up to 4.2) is available through extension loading - which means that these 3.0 headers would be fine even if I develop against 4.2 - I'll just load all 4.2 core functionality as extensions.
I read somewhere else that the gl.h header does indeed expose different functions between 4.2 and 3.0 - I just can't verify anything, since I find so many outdated articles and no solid information.
Can someone explain how all this fits together?
Your best bet is probably just to use a third party extension manager like GLEW (The OpenGL Extension Wrangler Library). It's pretty easy to use and contains all the latest extensions.
Related
I know Swift is not yet ABI stable, but does that only count for major versions of Swift?
Is there any guarantee that minor or patch versions (under semantic versioning) of Swift are ABI stable?
I'm guessing there is no guarantee here, but just wanted to double check if anyone has come across anything detailing ABI stability for different minor/patch versions of Swift.
Also, if I use a Swift binary framework compiled with a different version of Swift I get a compiler error usually. If I don't get a compiler error in my project does that mean it is safe, or could there still potentially be runtime issues with a slightly different (patch version) of Swift?
Update 3
We also have module stability, starting with Xcode 11, with the help of the newly introduced .swiftinterface files. One caveat, though, is that the code will have to be build with the -enable-library-evolution flag. More details here.
Update 2 Module stability is scheduled for Swift 6: https://swift.org/blog/abi-stability-and-more/#module-stability
This is an excerpt from the Swift evolution repo.
Update Swift 5 comes with some ABI stability:
The Swift 5 release will provide ABI stability for the Swift Standard Library.
Unfortunately, not yet. For Swift 4, they state this here: https://swift.org/blog/swift-4-1-release-process/.
Swift 4.1 is not binary compatible with 4.0. It contains a variety of under-the-hood changes that are part of the effort to stabilize the Swift ABI in Swift 5.
Hopefully we'll get ABI stability in Swift 5
I think we should know what is ABI stability firstly, After that your confusion has already been removed.
Today, the latest version of Swift is 3.1, so chances are if you ship an app tomorrow, your app bundle will contain the Swift dynamic libraries for 3.1, however, there are plenty of apps in the store right now which link 3.0, 2.3, and probably even some older apps that link 2.1 and earlier. Nothing is stopping me from downloading your app (on 3.1) and my app (on 2.3) and running them side-by-side on my iPhone with iOS 10.3, since both apps link against their own bundled version of Swift. It's exactly the same as you bundling Alamofire 4.4 and while I bundle 3.0.
When a language is ABI-stable (Application Binary Interface), that means it is packaged and linked with the operating system itself, in this case: iOS. The Swift code you compile on your computer has a binary interface into the operating system itself rather than any dynamic library you bundle with your application. Because of this, Apple has to be able to guarantee that my Swift code, when compiled to machine code (bitcode, LLVM-IR, yada-yada), will be able to interface properly with the rest of the operating system, and (probably more importantly) will not break between versions of iOS / Swift.
As it stands today, the Swift language specification and compiler are not in a state where the Swift team would feel comfortable making this promise of ABI-stability; changes to Swift are still too frequent and the roadmap is still too long. As soon as the Swift library is merged into iOS, it becomes much much harder to make big changes.
Why does it matter?
Yes, the bundle size of your application will decrease because you will no longer have to include the Swift standard library in your Frameworks folder, which is nice.
Language changes will be smaller / less frequent, so you won't have to worry about events like migration from Swift 2 -> 3 (I'm still scarred from that)
Developers will be able to create 3rd-party libraries written in Swift and distribute pre-compiled frameworks (binaries), because they no longer need to bundle the Swift standard library into their framework, and will instead be linking against the same version of Swift as your app (the one packaged with iOS).
I have a project that was started using swift 2 in xcode 7. I am now using swift 2.3 in xcode 8. When I try to migrate to pro 3 I get several errors no project. Both from the libraries and from my code. First I update my pods and then do an automatic conversion of the project. My doubts are:
In case some library can give rise to error I can unlock it and convert?
Do I have to prepare something before starting the conversation? In the articles I read about it, I did not say anything else about it.
In case you continue using swift 2.3 will you have any future problems?
The application is very large, what would be the best option?
Honestly? Any project built with Swift since 2014 should be done with an understanding of code will break with every new version through Swift 3.X. (I'm not at all being critical, just practical.) This year, Swift 4.X is working hard to not break Swift 3.X code.
So with that starting point, here's my thoughts:
Take a backup of a working Swift 2.X app and archive it. Backup that backup.
Accept the price that should have been known when using any version before 3.X - the conversion will be painful and time-consuming.
Wherever possible, do not use third party add ins. They can add to the complexity of migrating to the latest version.
Do consider waiting for Swift 4. I'm not recommending this at all, but saying consider the big picture. But always remember eventually you will have to port things. (The good news is Swift 3 appears stable enough to say future upgrade will not be (at least) as painful.
Consider migrating everything at once. (If you have that golden backup duplicated in several places, that makes it easier.) Yes, there are ways to migrate individual project, files, etc. from 2.X to 3.X - and 4.X (along with what is likely Xcode 9) makes things easier going forward. But only if you are starting from 3.X.
Regards to Swift 2.3... the latest version of Xcode will not compile/build Swift 2.3. Take that as a sign - someday it will no longer be accepted in the App Store. That day may be 2-3 years away (or not), but It's almost 2 years since the promises of ABI and version compatibility were meant for Swift 3.0. BTW, only the latter happened.
EDIT: Regards to point #3 (avoid third party add ins where possible), I found two links expressing the issues that can come up:
Analyzing Third Party Libraries
Avoiding Third Party UI Libraries
CorePlot looks like the best library going for the iPad apps I'm looking into, but I've been fighting all day just to get it to compile in an OS 6.1 project set to use Core Date, ARC, and unit tests.
I want to use those specs, but I'm starting fresh, with no other code that needs salvaged, so it occurred to me that rather than fight through the tutorials that don't address installation in ARC; and through the fixes for ARC that never seem to get me all the way to compile-able; that I could easily take any bare-bones project with those basic specs and start bringing in the simpler additions I've already figured out.
Anything like that out there?
All of the CPTTestApp example apps for both Mac and iOS have been converted to use ARC. This was done after the 1.1 release, so at the moment you'll need to pull the latest code with Mercurial to see the changes.
Since the 1.0 release, no changes to the Core Plot project is required to use it in an app that uses ARC. The Core Plot header files will compile under all supported SDKs with and without ARC. Include the Core Plot static library in your app, either the pre-compiled version or one built as a dependent project, and it will link and run just fine.
Core Plot does not use ARC internally because it still supports older systems that cannot use it. It will be updated when the minimum supported system is increased to one that supports ARC on both Mac and iOS.
I am developing an image processing application in Centos with OpenCV using C/C++ coding. My intension is to have a single development platform for Linux and IOS (IPAD).
So if I start the development in a Linux environment with OpenCV installed ( in C/CPP ),Can I use the same code in IOS without going for Objective-C? I don't want to put dual effort for IOS and Linux, so how to achieve this?
It looks like it's possible. Compiling and running C/C++ on iOS is no problem, but you'll need some Objective-C for the UI. When you pay some attention to the layering/abstraction of your modules, you should be able to share most/all core code between the platforms.
See my detailed answer to this question:
iOS:Retrieve rectangle shaped image from the background image
Basically you can keep most of your CPP code portable between platforms if you keep your user interface code separate. On iOS all of the UI should be pure objective-C, while your openCV image processing can be pure C++ (which would be exactly the same on linux). On iOS you would make a thin ObjC++ wrapper class that mediates between Objective-C side and the C++ side. All it really does is translate image formats between them and send data in and out of C++ for processing.
I have a couple of simple examples on github you might want to take a look at: OpenCVSquares and OpenCVStitch. These are based on C++ samples distributed with openCV - you should compare the C++ in those projects with the original samples to see how much altering was required (hint: not much).
The Boost Graph Library is a header-only library and does not need to be built to be used.
it contains some pre-made functions that I want for my iOS application:
dijkstra_shortest_paths
astar_search
However, Boost is not officially supported on iOS (or Android) due to lack of regression testing, and I'm not experienced enough with either Boost or iOS to be comfortable testing it.
Is anyone using Boost.Graph on iOS, and if so is it stable?
Yes, most definitely it's stable.
Apple's LLVM compiler (which is what you should be using for iOS apps) is one of the most C++11 compliant compilers available today, and as such can compile and run boost with absolutely no issues.
Not to mention the fact that iOS is also fully POSIX compliant, which makes most frameworks out there viable for use on iOS. When in doubt, try it and then if it doesn't work, come back and ask a question.
Leverage what is already there, and use it well!
As such boost libraries are stable, but Boost Graph libraries are failing on all darwin flavours (darwin- 4.4_0x intel- darwin- 12.0 intel- darwin- 11.1 darwin- 4.4)
http://www.boost.org/development/tests/release/developer/summary.html
May be you can try other alternatives, like LEDA (http://www.algorithmic-solutions.com/news/archive.htm)
Thanks.