Archive

Posts Tagged ‘xcode’

Print TODO/FIXME Comment as Warning in XCode

July 12, 2011 Leave a comment

When I’m implementing new functionality I start with the general design and then I’m implementing newly created classes and methods. Sometimes I leave a method or two for later implementation (i.e. after creating unit test for this method) and almost always putting comment:

// TODO: nice comment here

It already happened to me, that I left this comment unnecessary or (the worst case scenario) I forgot to implement this TODO part 😦 To get rid of these mistakes you can add Run Script phase in Build Phases of your project’s target with some nice shell command. To do this, click on your target, move to Build Phases tab and in right-bottom corner click Add Build Phase and choose Add Run Script. Leave shell as it is and in the content of the script paste following two lines:

KEYWORDS="TODO.*:|FIXME.*:|\?\?\?.*:|\!\!\!.*:"
find "${SRCROOT}" \( -name "*.h" -or -name "*.m" -or -name "*.mm" \) -print0 | xargs -0 egrep --with-filename --line-number --only-matching "($KEYWORDS).*\$" | perl -p -e "s/($KEYWORDS)/ warning: \$1/"
At the end of second line you can add i.e.:
| grep -v ExternalSources
This will prevent from printing warnings for TODO/FIXME comments in file paths containing “ExternalSources”. It’s in case you use third party source code that still needs some work to be done 🙂
The latest revision of this script can be found at my github repository: todo xcode gist
Categories: mac, programming Tags: , ,

Moving Files in XCode

July 12, 2011 2 comments

Couple of times I made silly mistake of creating new files in XCode project not in the place I want them to be in filesystem. Groups and “real” folders still confuse me. When you have such file in your project that is in correct group, but not in correct folder on the disk and you don’t want to remove it’s reference and add the same file again I have two steps solution for you.

First you open Finder (or any other file commander tool) and move the file to the correct location. When you will open XCode you will see that this moved file is red now (this is expected behavior, XCode cannot find this file under old location):

What you have to do is to highlight this file and open File Inspector (menu View -> Utilities -> File Inspector or by keyboard shortcut <command> + <option> + <1>). Just under Location combo box there is specified current location for this file. Hit the little folder icon on the right and choose the new path of the moved file:

And that’s it. The drawback of this solution is that you have to repeat this steps for each file you want to move, but if you have plenty of them, probably it’s better to remove references and add them again.

Categories: mac, programming Tags:

Git(Hub) and Mac Line Endings

December 8, 2010 1 comment

During my first project created in X-Code which I wanted to store in public GitHub repository I encountered issue with showing content of my source files on GitHub web page. After contacting with GitHub support (btw, they answer really fast and are helpful) they pointed out my line endings.

Quick recon brought surpassing results. I realized that even modifying single line of code in the source file, git shows modification in the whole file, because it sees this file as a single line (Mac line endings was shown as ^M). Why I didn’t noticed it earlier? Don’t know. I’m a noobie on Mac.

The first solution for GitHub web page was to set following git config attribute:

git config --global core.autocrlf input

It should commit files with Unix line endings. I know it works in Windows, but somehow it hadn’t worked for me on my Mac. Creating new project from scratch didn’t help either and even if it would help for files committed to the repository, my local git problem is still not resolved.

The solution was to set in X-Code configuration (Command + “,”) line ending for new and existing files to Unix (LF) instead of Mac (CR):

It solved issues with newly created files, but old ones was still invalid (maybe someone will explain me how this “For existing files” option works). Following command executed on all current files, which simple swaps line endings, solved the issue:

tr '\r' '\n' < <old_file> > <new_file>
Categories: programming Tags: ,

Integrating Boost Test Framework with X-Code

November 30, 2010 Leave a comment

Usually people are using X-Code for creating applications in Objective-C, but this IDE is also useful for C++ programming.When you are creating something, you want to test it (or you should want to). One of the unit test framework is Boost::Test. I will describe shortly how to integrate this framework with X-Code (currently 3.2.4).

 

Requirements:

  • X-Code IDE
  • Boost library installed (you can use MacPorts)

 

Creating Project

I will use simple command line tool project for this tutorial. You can choose whatever you need for your project but it should be using C++ programming language.

 

Creating Target

First you have to create new test target for the project. You can do it by right-clicking Target group in X-Code IDE and choosing Add – New Target from context menu. Choose BSD group and Shell Tool template. Input name for the target (e.g. “Unit Tests”) and continue.

Now you have to specify include and library paths for newly created target. Right-click on the new target and choose “Get Info”. Go to Build tab and search for “Header Search Path” and input path to include files from Boost library (when installing from MacPorts the path is /opt/local/include). Next search for “Always Search User Paths” and mark it. The last one is “Library Search Paths” where you have to input path to compiled Boost libraries (when MacPorts – /opt/local/lib).

 

 

Next thing to do for making Boost Test work is to input “-lboost_unit_test_framework” in “Other Linker Flags” setting from test target’s info Build tab.

The last thing to do is to add Run Script. It can be done by right-clicking test target and choosing Add – New Build Phase – New Run Script Build Phase. In Script section paste following text:

"${TARGET_BUILD_DIR}/${EXECUTABLE_NAME}"

 

First Unit Test

Now you can start creating your test suites and test cases. Create new C++ implementation file (without a header) and remember to add it to your’s unit test target.

 

 

Paste this code sample:

#include <boost/test/unit_test.hpp>

BOOST_AUTO_TEST_SUITE(smoke_suite)
BOOST_AUTO_TEST_CASE(smoke_test)
{
BOOST_CHECK_EQUAL(1, 2);
}
BOOST_AUTO_TEST_SUITE_END()

You can create as many such files as you wish, but they need to be tight together by the one, which content is presented below (this is also C++ implementation file and also should be added to test target):

#define BOOST_TEST_DYN_LINK
#define BOOST_TEST_MODULE my_unit_tests
#include <boost/test/unit_test.hpp>

Now you are ready to run your first test suite. Right-click on the test target and choose Build. It will compile and … you will see error. It is because our tast case should fail. You can go directly to the source of the error bu clicking on the error from the build process:


 

After fixing the test the build process should finish successfully.

 

Integrating Tests with Project

It will be better to make X-Code run tests automatically during compilation of our main project, so we will now tie our main project with the test suite. It can be done by right-clicking your main project target and choose Get Info. Being on the General tab you have to add Dependency of test target. Now whenever you will compile the project, unit test will be run.

More about Boost Test framework itself can be found here.

Categories: programming Tags: , ,