After upgrading to Mountain Lion, the following all seemed to be broken:
- MacPorts… Issuing a selfupdate command produced:
checking whether the C compiler works... no
configure: error: in '/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/base':
configure: error: C compiler cannot create executables |
- make…
- cmake…
error: There is no SDK with the name or path '/Developer/SDKs/MacOSX10.8.sdk' |
The solution to these problems were fairly simple:
A few minutes later, I was back in business compiling the Pharo Smalltalk VM!
Apparently, gcc 4.2 is no longer installed with Xcode (as of Xcode 4.2). Unfortunately, older projects may need to be compiled with gcc. There is some scattered information online about how to get gcc 4.2 with Xcode 4.2, but they seem complex and error-prone (e.g. install Xcode 4.1, then upgrade to 4.2).
UPDATE: Here are some situations you might find yourself in:
- Upgrading from Snow Leopard to Lion – it seems that gcc et al will be moved to a different location. See here for a fix.
- Upgrading to Xcode 4.2 – gcc 4.2 should still be on your machine; you just have to tell Xcode 4.2 to list it as an option (in which case, skip to step #2 below)
- Installing Xcode 4.2 with no previous version – no gcc 4.2 at all; follow instructions below.
Here’s an easy way to get gcc 4.2 working [1]:
1) Install gcc 4.2. via Mac Ports:
sudo port install apple-gcc42 |
2) Tweak Xcode so that gcc 4.2 appears as a compiler option, by editing the Xcode 4.2 GCC 4.2.xcspec file to get gcc 4.2 to show in the list of compiler options:
- Open the xcspec file for editing:
sudo vi "/Developer/Library/Xcode/PrivatePlugIns/Xcode3Core.ideplugin/Contents/SharedSupport/Developer/Library/Xcode/Plug-ins/GCC 4.2.xcplugin/Contents/Resources/GCC 4.2.xcspec" |
- Change lines 41 and 42 from this:
ShowInCompilerSelectionPopup = NO;
IsNoLongerSupported = YES;
To This:
ShowInCompilerSelectionPopup = YES;
IsNoLongerSupported = NO;
- Link the gcc 4.2 binary to the location that Xcode expects
sudo ln -s /opt/local/bin/gcc-apple-4.2 /Developer/usr/bin/gcc-4.2
sudo ln -s /opt/local/bin/g++-apple-4.2 /Developer/usr/bin/g++-4.2 |
[1] Adapted from this Stack Overflow thread
For a while, I’ve been thinking about using MacRuby for native UIs and multiple windows in Pharo on the Mac. I uploaded a proof of concept to https://github.com/seandenigris/PharoMacRubyTest . It has a simple Cocoa UI that uses http to get a value (the current time) from a running Pharo image and displays it in a text field. See the discussion on the Pharo mailing list.
Xcode 4.1 had a bug where IB did not recognize outlets in MacRuby classes. It is corrected in Xcode 4.2. However, if you upgrade to 4.2, you must then reinstall MacRuby for MacRuby outlets to start working again.
See this StackOverflow thread for the more information.
Have you wanted to automate your Xcode workflow, but couldn’t figure out exactly how to work the AppleScript commands? Well, here’s a whole object-oriented library of handlers for ya!
(Sorry I haven’t figured out a better way to format AppleScript code in a blog; any ideas, please let me know)
on target_object(the_target)
script target_obj
property target_ref : ""
to add_source_file(the_file)
tell application "Xcode"
add the_file to (get compile sources phase of target_ref)
end tell
end add_source_file
on set_header_search_paths_for_all_configurations(the_path)
tell application "Xcode"
(* configuration is Debug or Release *)
set value of build setting "HEADER_SEARCH_PATHS" of build configurations of target_ref to the_path
end tell
end set_header_search_paths_for_all_configurations
to add_run_script_phase(the_name, the_script)
tell application "Xcode"
tell target_ref
return make new run script phase with properties {name:the_name, shell path:"/bin/sh", shell script:the_script}
end tell
end tell
end add_run_script_phase
end script
tell application "Xcode"
set target_obj's target_ref to the_target
end tell
return target_obj
end target_object
on group_object(the_group)
script group_obj
property group_ref : ""
to add_file(the_path, the_file_name)
tell application "Xcode"
tell group_ref
return make new file reference with properties {full path:the_path, name:the_file_name}
end tell
end tell
end add_file
end script
set group_obj's group_ref to the_group
return group_obj
end group_object
on active_project()
script project_obj
property project_ref : ""
to add_group(group_name)
tell application "Xcode"
tell project_ref
-- Get project directory
set project_dir to project directory
-- Create new folder for group's files
tell application "Finder"
set file_lib to load script alias "Macintosh HD:Users:sean:Library:Scripts:My Library:Files.scpt"
make new folder at (file_lib's posix_string_to_hfs_file(project_dir)) with properties {name:group_name}
end tell
-- Create new group
tell root group
return my group_object(make new group with properties {name:group_name, path type:project relative, path:group_name} at beginning)
end tell
end tell
end tell
end add_group
to make_new_shell_tool_target(target_name)
tell application "Xcode"
tell project_ref
set unit_test_template to target template "BSD/Shell Tool"
return my target_object(make new target at end of targets with data unit_test_template with properties {name:target_name})
end tell
end tell
end make_new_shell_tool_target
end script
tell application "Xcode"
set project_obj's project_ref to project of active project document
end tell
return project_obj
end active_project
You can also download the scpt file here.
And here’s a script that uses the handlers.
My workflow in Xcode is typical TDD – write a test, run the tests, write some code, run the tests… I set up a “Run Script” build phase, so that every time I build the tests, they are automatically run. The only problem is that the “Run Script” happens whether the build was successful or not. So, I try to build and fail, and then the same exact tests that I already ran, automatically run again – while I sit there and wait.
The solution turned out to be very simple. “Run Script” build phases in Xcode can have input files and output files. The phase is only run if some input files were more recently modified than some output files. Thus, if we set the input file to be the test executable, and the output files to be all the source files, then the tests will only run if the build is successful. It will look something like this when set up:
I was working on an Applescript Studio project with Objective-C mixed in, when all of a sudden, without any warning or intervention from me, the debugger ceased to load when I ran the app (in debug mode). Hmmm, little gremlins, hackers from Russia???
After searching the lists and checking off the usual culprits (debug configuration, yes; debug symbols enabled, ditto), I went to my old-standby-last-resort-when-xcode-starts-acting-crazy-for-no-reason move: I created a fresh project, confirmed that it was working normally, and then opened every setting window in both projects to see what settings are different, and so could possible be contributing to the hiccup.
When I opened the settings for the executable (I was desparate), I noticed that the “Debugging->When using…” drop-down was different. Now, to you or I, “when using” seems to say “these setting only apply when you happen to be using X.” Yet on planet Xcode, it seems to translate into “when you change X, you’re project will begin to work in a different way then usual, even if you do not change any o the settings in this window.” I selected “GDB” from the drop-down, and all my problems were solved… maybe that’s a bit dramatic.
Anyway, my breakpoints are again working (in both the Obj-C and applescript code). Yay!
Recent Comments