Bug #1110
Provide Xcode Build Environment
100%
Description
With the arrival of Xcode 5 in 2013, Apple have withdrawn support for GCC on MacOS-X. They provide some GCC/GDB compatibility to enable Clang/LLDB to "sort of" work. However the Eclipse/GDB/STL "pretty printers" (written in Python) are hopelessly broken. Debugging Exiv2 in Eclipse can be painful. That's a pity because I find Eclipse easier to use than Xcode and more feature rich.
I've been expecting Eclipse/CDT to seamlessly enable Clang/LLDB debugging, however this isn't provided in the current 'Mars' Eclipse.
So, I'm adding an Xcode build environment. I could do this as a 'native' build environment which takes care of everything and builds libraries, sample applications, runs test. Or I could do this as wrapper over the existing autotools environment. That's what has been done.
Associated revisions
#1110 Adding more targets (config, configure)
#1110. Adding notes.
#1110 Reference files instead of groups of files.
#1110. Xcode project moved to contrib/xcode. Interesting errors in samples/Makefile. Replaced gsoc13 Exiv2::dict_t with (identical twin) Exiv2::Dictionary
#1110 Removed trunk/xcode
#1110 Xcode build environment upgraded for Xcode 8.0
History
Updated by Robin Mills about 6 years ago
- % Done changed from 0 to 30
- Estimated time set to 20.00 h
This "autotools wrapper" should always be "experimental/use without support". I'll add a "ReadMe.txt" to the project.
I intend to use this as my primary build/debug/IDE on the Mac and this project will improve - however it's really only here for my personal convenience.
Updated by Robin Mills about 6 years ago
- % Done changed from 30 to 100
- Estimated time changed from 20.00 h to 10.00 h
This isn't very good. It simply doesn't compare with our Visual Studio support. I've moved xcode into "contrib/xcode" and I'll use it to debug stuff on the Mac.
However this has been a useful exercise. I've discovered significant error in the -I include path in samples/Makefile which was causing us to pick up the wrong header file. And in the course of debugging that, I've replaced all gsoc13 legacy typedef Exiv2::dict_t with his identical twin brother Exiv2::Dictionary. And I've removed 'using std" from several sample apps. r3962
I might revisit this in future if I use it a lot and decide to make him as good as Visual Studio. That's possible. However it's probably 10-20 hours work to define the project to build static/dynamic and do the correct linking and everything. For the moment, this is OK.
Updated by Robin Mills about 6 years ago
You are 100% correct. CMake does indeed have generators both for Xcode and Unix Makefiles. I've used both to successfully build/debug exiv2 with Eclipse and Xcode. As you know there's always more than one way to do things. I've added contrib/xcode tree as I have found this useful.
#1110. Adding Xcode build environment.