On a Cocoa project I've been working on I am using Ragel to generate a parser by transforming the ragel source file into an intermediate Objective-C file that contains the parser class. The idea then is to use a custom build rule in XCode to handle updating the Objective-C when the ragel source changes and also compiling the derived source file.
I tried following the instructions Alan West posted about integrating Ragel with XCode but it just wouldn't work properly. I could see my derived source file getting created but the linker reported that the parser class was an unknown symbol. After digging around a bit with the command line
xcodebuild I could see that my source was created, but never compiled. Instead it was being copied into the bundle resources.
I read all about custom build rules and configurations, experimented with build scripts instead (couldn't get those to work either), and googled until I came across the author Fritz Anderson's online chapter from his book 'Step into XCode'. He's using Lemon instead of Ragel but was observing the exact same issue.
As I reflected on this it was also starting to bug me that my source would end up in the bundled resources. Why the hell would I want that? That's when the penny dropped. I noticed that my custom source file (DiffParser.ml.rl) was in the "Copy bundle resources" build phase but not in the "Compile sources" build phase. Once I moved it across everything worked properly and I was able to build my executable.
I guess XCodes behaviour makes sense. It didn't know anything about
.m.rl files when they were added to the project and so it's a reasonable assumption that they were resources. However if XCode had been really smart it should have noticed me defining a new build rule for
*.m.rl files and checked to see if any files that were previously considered to be resources should now considered source files and offer to move them to the correct phase for me.