CODEWITHSUNDEEP
iosobjective-cxcodebuildwarnings
ila
ila

Reputation: 920

Custom build conditions and Warnings Xcode

My iOS Project has a compulsion that every class a developer make must be prefixed by "SYV". I have to add build setting that if any class does not follow this convention it should be shown as a warning in Xcode.

I am not sure where to start or its even possible. Please advice.

Upvotes: 2

Views: 1120

Answers (1)

hagi
hagi

Reputation: 11823

This is possible but needs some work which I'm not sure is worth it. How many classes will be in the project? If it's not a large project, manual code review should do the job. However, if you want to follow your plan, here's what you can do:

Approach 1: Put all your classes in one folder (or subfolders). Given that you only put one class in each file, and the class is named after the file, you can have a very simple script that just validates all file names, maybe recursively, if you want to have some structure.

Approach 2: Use Xcode Build Rules: Specify a new rule for *.m files (and maybe *.h, too, if you want to be sure). As this overwrites the default rule (compiling the files) and I don't know an easy solution to execute the default rule afterwards, I'd suggest you create an extra target for validation only, which doesn't need to compile. You then need a custom script that parses the source files, finds class @implementations (assuming every class is implemented, I can't see a reason to check @interfaces directly, but I may be missing something here), and validates their names. You could probably get away with some regex, or fully parse the files using libclang. If you implement the validation in a C-based (C, C++, Objective-C,...) command-line tool that is called from your build rule script, you can use this to generate warnings that show up in Xcode:

// casts are only added as hints to the types used
printf("%s:%d: warning: %s", (string)symbolName, (int)lineNumber, (string)text);

I haven't found a way to generate warnings from bash scripts directly though. More Infos on build rules can be found here.

Approach 3: Similar to 2, but instead of overwriting build rules, you could add a script that is executed during compilation, by defining a Build Phase. The challenge here is to find all relevant classes that the target uses. You could manually inspect the .pbxproj file to get that information (not really recommended, but a nice exercise), or use a library like mod-pbxproj (Python) or Xcodeproj (Ruby). Then proceed with the validation as in approach 2.

Approach 4: You could also implement a Clang extension by adding a compiler flag and code to check the prefix. This could be done by modifying the compiler itself, by adding an analyzer plugin, or writing a Clang-based tool (which could be called from a script as in approaches 2/3). This is not trivial, but can be done. eero and this modified Clang compiler can be used as examples if you want to take this path.

Recommended reading:
objc.io: The Build Process
Xcode Project vs. Xcode Workspace - Differences

Upvotes: 1

Related Questions