Bug #1110

Provide Xcode Build Environment

Added by Robin Mills over 1 year ago. Updated over 1 year ago.

Status:ClosedStart date:27 Aug 2015
Priority:NormalDue date:
Assignee:Robin Mills% Done:

100%

Category:buildEstimated time:10.00 hours
Target version:0.26

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

Revision 3900
Added by Robin Mills over 1 year ago

#1110. Adding Xcode build environment.

Revision 3903
Added by Robin Mills over 1 year ago

#1110 Adding more targets (config, configure)

Revision 3906
Added by Robin Mills over 1 year ago

#1110. Adding notes.

Revision 3915
Added by Robin Mills over 1 year ago

#1110 Reference files instead of groups of files.

Revision 3962
Added by Robin Mills over 1 year ago

#1110. Xcode project moved to contrib/xcode. Interesting errors in samples/Makefile. Replaced gsoc13 Exiv2::dict_t with (identical twin) Exiv2::Dictionary

Revision 3963
Added by Robin Mills over 1 year ago

#1110. Correction to r3962

Revision 4023
Added by Robin Mills over 1 year ago

#1110 Removed trunk/xcode

Revision 4496
Added by Robin Mills 8 months ago

#1110 Xcode build environment upgraded for Xcode 8.0

History

#1 Updated by Robin Mills over 1 year ago

  • % Done changed from 0 to 30
  • Estimated time set to 20.00

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.

#2 Updated by Robin Mills over 1 year ago

  • % Done changed from 30 to 100
  • Estimated time changed from 20.00 to 10.00

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.

#3 Updated by Robin Mills over 1 year ago

  • Status changed from Assigned to Resolved

#4 Updated by Daniel Kaneider over 1 year ago

CMake would have an XCode generator

#5 Updated by Robin Mills over 1 year 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.

#6 Updated by Robin Mills over 1 year ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF

Redmine Appliance - Powered by TurnKey Linux