I don’t do this often enough to remember, so I figured I’d write it down. For example, to look for all the places where you include stdio.h in .cpp files below the current directory:
$ grep -r -n --include "*.cpp" '#include <stdio.h>' .
I don’t do this often enough to remember, so I figured I’d write it down. For example, to look for all the places where you include stdio.h in .cpp files below the current directory:
$ grep -r -n --include "*.cpp" '#include <stdio.h>' .
Typically, tea needs to brew from 4-5 minutes. You’re probably smart enough to figure out the rest of what’s going on here:
$ sleep 240; say "Tea's Done"
Edit 25-Nov-2009: I guess there’s no reason I couldn’t make a MacRuby app out of this, huh?
I am collaborating on a project right now where multiple developers may be making changes to a single Xcode project. Since in my experience, Xcode project files “don’t merge well,” we have setup git so it treats the Xcode project file (project.pbxproj) as if it were a binary. Consequently, it sucks to have too many outstanding changes to the Xcode project file that have to be merged back in manually. To help shorten the amount of time someone might be working on an out of date Xcode project file, I setup a post-commit hook on the git repository that sends email to the developers in case this particular file changes.
Procedure:
[hooks] mailinglist = you@example.com someoneelse@example.com
git show --pretty="format:" --name-only HEAD | grep project.pbxproj if [ $? -eq 0 ]; then mail $(git config hooks.mailinglist) -s "Xcode project changed" <<-EOF Please pull the latest Xcode project. EOF fi
chmod +x post-commit
That’s it! Piece o’ cake, huh? Anyway, even if my logic regarding the “mergability” (or lack thereof) of an Xcode project is flawed, the principle behind email notification on a single file is still valid. I’m sure generalizing this to notify upon changes to a list of files is easy enough.
With some encouragement from my colleagues, I expanded the original post here to be a more soup-to-nuts recipe for setting up CC.rb with git and xcodebuild on Mac OS X. Thanks, guys!
I am currently working on a cross-platform project which has multiple targets that need to build on Mac OS X. On my previous project, we were using CruiseControl.rb on linux to watch a Subversion repository for a Rails project and run all the associated tests upon checkin. Since we wanted to be like the Cool Kids on this new project, we of course decided to use git for source code management. We use gitosis to manage multiple remote git repositories under a single user. However, you can use any approach you want for the remote repository management as long as you can compose a git URL that points to it.
Assumptions:
Procedure:
It took a little doing to make CC.rb play nice on Mac OS X. In addition to the typical CC.rb installation, getting CC.rb to launch at system startup using launchd took the proper file in the proper location. Nevertheless, the whole setup is pretty darned straightforward. Here’s how I did it:
/Users/continuousintegration/cruisecontrol.rb
./var/cruise
as the work directory. This required admin privileges to create; just make sure that your CI user has access to this directory.
sudo mkdir /var/cruise sudo chown continuousintegration /var/cruise
cd ~/cruisecontrol.rb ./cruise add <project name> --url <git repository url> -s git
cruise_config.rb
. This provides some useful configuration information so that CC.rb knows what to do in order to build your project as well as whom to notify when the build fails. You provide the build command for CC.rb in cruise_config.rb
by assigning to project.build_command
. I actually made my build command point to ./ci_build.sh
so that I can do anything I want for the build in a separate shell script named ci_build.sh
in the git repository root. In my case, I am actually running xcodebuild
to build a target I created in my Xcode project; you can do literally anything you want here, e. g. make check, rake
… whatever! Witness my cruise_config.rb
and ci_build.sh
files. (If you create a ci_build.sh
or equivalent file, be sure you make it executable.) Make sure you git push
your changes to add the cruise_config.rb
(and ci_build.sh
if you choose to do so)../cruise start
Browse to http://localhost:3333
/Library/LaunchDaemons
which starts up CC.rb. (For more information on what’s going on here, see the Apple documentation or man launchd
.)/Library/LaunchDaemons
sudo cp localcruisecontrol.plist.txt /Library/LaunchDaemons/local.cruisecontrol.plist
Now when you restart the CI machine, CC.rb should start up automatically.
Setting up CC.rb all by itself tends to be pretty easy; it’s getting the daemon to run at system startup as well as getting your build to work properly that tend to be the problems. If you’re having trouble getting things running after following these directions, or if you find errors in these directions, please let me know.
We used to use command output (COMO) files all the time way back in the days of PRIMOS. Funny how I accidentally stumbled upon the Unix equivalent today — the script
command — approximately 25 years later. Not sure what I’d use it for since we have redirection on Unix, but always good to learn something new.
I finally made an honest blog out of this thing.
I was building a new project to do some experiments with wchar_t this morning. (Look here for the reason.) It seemed to me it took way longer than it should simply to get a CppUnit project setup in Xcode with a single test case. (It was primarily due to C++ and pilot error; I gotta say I’m gonna get a cold constantly moving between Ruby and C++.)
Consequently, I have built a skeleton CppUnit Xcode project. This provides you with a single class with a test method which asserts FALSE, demonstrating that the test process is working properly. It’s up to you to do something interesting with this head start.
Prerequisite for all platforms: install CppUnit.
If you’re on Mac OS X, with any luck you can simply build-and-go and you’ll see the results of the test (failure) in the debugger console.
If you’re on Linux, just disregard everything Xcode-related; you can still build and run the code from the command line (see the README file).
If you’re on Windows, gosh I’m sorry. 🙂 Nevertheless, you should be able to load these files into Visual Studio, set your header search directory to wherever CppUnit is installed, add the CppUnit library to your project, build and run.
Please let me know if you have any problems with this so I can keep it updated and hopefully save others a little time during CppUnit ramp up. Now GO WRITE A TEST!
Here’s the configure command I used to build a universal binary for log4cpp on Mac OS X:
$ env CFLAGS="-O -g -isysroot /Developer/SDKs/MacOSX10.5.sdk -arch i386 -arch ppc" \
LDFLAGS="-arch i386 -arch ppc" \
CXXFLAGS="-O -g -isysroot /Developer/SDKs/MacOSX10.5.sdk -arch i386 -arch ppc" \
./configure --disable-dependency-tracking
I have a share on Windows that is mounted to Ubuntu. The filenames on Windows contain Unicode characters. When mounted to Ubuntu, the “special” characters appeared as question marks.
The solution to this problem required a lot of research, but in the end turned out to be straightforward:
In the entry for mounting the share in /etc/fstab:
iocharset=utf8
Even if you have a column in a table that is specified as nvarchar, you still need to tip off SQL Server that you are handing it a string that contains Unicode when you’re setting values in the column. Witnesseth:
1> create table interjunk(id int not null, inter nvarchar(255))
2> go
1> insert into interjunk(id, inter) values (1, 'Unicode string ψ')
2> insert into interjunk(id, inter) values (2, N'Unicode string ψ')
3> go
(1 row affected)
(1 row affected)
1> select * from interjunk
2> go -m vert
id: 1
inter: Unicode string ?
id: 2
inter: Unicode string ψ
(2 rows affected)