<NME> README.md
<BEF> [![Gem Version](https://badge.fury.io/rb/mayday.svg)](http://badge.fury.io/rb/mayday)
[![Build Status](https://travis-ci.org/marklarr/mayday.svg?branch=master)](https://travis-ci.org/marklarr/mayday)


Easily add custom warnings and errors to your Xcode project's build process

## Installation
```sh
$ gem install mayday
```

## Usage

Create a Maydayfile

```sh
$ mayday init
```

Add some warning and error checks to that file

```ruby
# Maydayfile

# Required
xcode_proj "CoolApp.xcodeproj"

# Use regular expressions to define errors or warnings on a line-by-line basis
error_regex "Please remove Copyright boilerplate", /^\/\/  Copyright \(c\).*$/, :files => "*AppDelegate*"
warning_regex "TODO", /^\/\/\s+TODO:.*$/
```

You can do more advanced checks, too, with blocks

``` ruby
# Maydayfile

warning :line, :exclude => "Fixtures/SomeDir/Excluded/*" do |line|
  line.length > 120 ? "Length of line #{line.length} is longer than 120 characters!" : false
end

# You can get the whole file, too
error :file do |entire_file|
  max_number_of_lines = 500
  
  number_of_code_or_comment_lines = entire_file.split("\n").select { |line| line.strip.length > 0 }.count
  if number_of_code_or_comment_lines > max_number_of_lines
    # Map line numbers to errors
    { "1" => "File is #{number_of_code_or_comment_lines} lines long" }
  else
    false
  end
end
```

When you're ready, run

```sh
$ mayday
```    

Next time you build your project, your errors and warnings will be flagged

![Mayday warnings and errors in Xcode](https://raw.githubusercontent.com/marklarr/mayday/master/docs/example.jpg?token=760261__eyJzY29wZSI6IlJhd0Jsb2I6bWFya2xhcnIvbWF5ZGF5L21hc3Rlci9kb2NzL2V4YW1wbGUuanBnIiwiZXhwaXJlcyI6MTQxNDM5MDIxNH0%3D--e7969b95aea1bc76749ae9226d2ac5ffef0cf322)

![Mayday warnings and errors in Xcode, inline](https://raw.githubusercontent.com/marklarr/mayday/master/docs/example_inline.jpg?token=760261__eyJzY29wZSI6IlJhd0Jsb2I6bWFya2xhcnIvbWF5ZGF5L21hc3Rlci9kb2NzL2V4YW1wbGVfaW5saW5lLmpwZyIsImV4cGlyZXMiOjE0MTQzOTAzMzh9--bc9abbe40843317e7b6a30a9521ebf6ae457ece2)

You can also run mayday from the command line

```sh
$ mayday run
```

You also have the option to choose the file specifying the project and rules (by default this will be `Maydayfile`) using

```sh
$ mayday run --rules MyRulesFile
```

Since Ruby is installed by default on OSX, the warnings and errors will work for anybody building your project, even if they don't have RVM, RubyGems, or mayday.

### Options

`warning`, `error`, `warning_regex`, and `error_regex` all accept an options hash with any of the following options

* `language` limits to files in the provided language. Accepts `"swift"` and `"objective-c"`.
  * `warning :line, :language => "swift" do ...`

## Caveats

* `mayday` uses [sourcify]() to write your custom `warning` and `errors` blocks to a build phase, all [gotchas in sourcify](https://github.com/ngty/sourcify#gotchas) apply to your blocks.
* `mayday` copies your custom blocks, line for line, into a build phase, so all variables inside of them must be of local scope. Anything defined outside of a custom block will not be included in the build phase.
* Gems cannot but used inside of custom blocks, only vanilla, system Ruby.
* If your custom blocks have errors in them that aren't found until they're executed (which is done whenever you call `mayday`), the stack trace won't be very helpful in debugging (because there is no source map from the build phase back to your `Maydayfile` code)
For some ideas on how to start using mayday, see the [cookbook](https://github.com/marklarr/mayday/blob/master/docs/Cookbook.md)

## Benchmarking

You may be concerned about how much overhead this will add to your build process. To see how quickly your `mayday` checks execute, use 

```sh
$ mayday benchmark
```

## Caveats

* `mayday` uses [sourcify](https://github.com/ngty/sourcify) to write your custom `warning` and `errors` blocks to a build phase, all [gotchas in sourcify](https://github.com/ngty/sourcify#gotchas) apply to your blocks.
* `mayday` copies your custom blocks, line for line, into a build phase, so all variables inside of them must be of local scope. Anything defined outside of a custom block will not be included in the build phase.
* Gems cannot be used inside of custom blocks, only vanilla, system Ruby.
* If your custom blocks have errors in them that aren't found until they're executed (which is done whenever you call `mayday`), the stack trace won't be very helpful in debugging (because there is no source map from the build phase back to your `Maydayfile` code)
* Generating efficient code to write into the build phase is difficult. The code generated by `MayDay::ScriptGenerator#to_ruby` could definitely be optimized.

## Uninstallation

```sh
$ mayday down
```

## Contributing

We'd love to see your ideas for improving this library! The best way to contribute is by submitting a pull request. We'll do our best to respond to your patch as soon as possible. You can also submit a [new GitHub issue](https://github.com/marklarr/mayday/issues/new) if you find bugs or have questions. :octocat:

Please make sure to follow our general coding style and add test coverage for new features!

<MSG> Merge pull request #4 from Keithbsmiley/ks-readme-fix

Add readme link
<DFF> @@ -88,7 +88,7 @@ $ mayday benchmark
 
 ## Caveats
 
-* `mayday` uses [sourcify]() to write your custom `warning` and `errors` blocks to a build phase, all [gotchas in sourcify](https://github.com/ngty/sourcify#gotchas) apply to your blocks.
+* `mayday` uses [sourcify](https://github.com/ngty/sourcify) to write your custom `warning` and `errors` blocks to a build phase, all [gotchas in sourcify](https://github.com/ngty/sourcify#gotchas) apply to your blocks.
 * `mayday` copies your custom blocks, line for line, into a build phase, so all variables inside of them must be of local scope. Anything defined outside of a custom block will not be included in the build phase.
 * Gems cannot but used inside of custom blocks, only vanilla, system Ruby.
 * If your custom blocks have errors in them that aren't found until they're executed (which is done whenever you call `mayday`), the stack trace won't be very helpful in debugging (because there is no source map from the build phase back to your `Maydayfile` code)

{'commit': "diff --git a/README.md b/README.md\nindex b9a9a7f..62ae53e 100644\n--- a/README.md\n+++ b/README.md\n@@ -88,7 +88,7 @@ $ mayday benchmark\n \n ## Caveats\n \n-* `mayday` uses [sourcify]() to write your custom `warning` and `errors` blocks to a build phase, all [gotchas in sourcify](https://github.com/ngty/sourcify#gotchas) apply to your blocks.\n+* `mayday` uses [sourcify](https://github.com/ngty/sourcify) to write your custom `warning` and `errors` blocks to a build phase, all [gotchas in sourcify](https://github.com/ngty/sourcify#gotchas) apply to your blocks.\n * `mayday` copies your custom blocks, line for line, into a build phase, so all variables inside of them must be of local scope. Anything defined outside of a custom block will not be included in the build phase.\n * Gems cannot but used inside of custom blocks, only vanilla, system Ruby.\n * If your custom blocks have errors in them that aren't found until they're executed (which is done whenever you call `mayday`), the stack trace won't be very helpful in debugging (because there is no source map from the build phase back to your `Maydayfile` code)\n", 'commit_subject': 'Merge pull request #4 from Keithbsmiley/ks-readme-fix', 'repo_name': 'marklarr/mayday', 'committer': {'name': 'Mark Larsen', 'email': '74746901036edce25b14cf16eb3fd9385815c8c1@gmail.com', 'time_sec': '1414019873', 'tz_offset': '-420', 'date': {'seconds': '1414019873'}}, 'commit_tree': '6cc1cd85ebe45b67fe5cc8cf0596e75dd949e408', 'commit_message': 'Merge pull request #4 from Keithbsmiley/ks-readme-fix\n\nAdd readme link', 'language_name': 'Ruby', 'license': 'mit', 'hunks': "@@ -88,7 +88,7 @@ $ mayday benchmark\n \n ## Caveats\n \n-* `mayday` uses [sourcify]() to write your custom `warning` and `errors` blocks to a build phase, all [gotchas in sourcify](https://github.com/ngty/sourcify#gotchas) apply to your blocks.\n+* `mayday` uses [sourcify](https://github.com/ngty/sourcify) to write your custom `warning` and `errors` blocks to a build phase, all [gotchas in sourcify](https://github.com/ngty/sourcify#gotchas) apply to your blocks.\n * `mayday` copies your custom blocks, line for line, into a build phase, so all variables inside of them must be of local scope. Anything defined outside of a custom block will not be included in the build phase.\n * Gems cannot but used inside of custom blocks, only vanilla, system Ruby.\n * If your custom blocks have errors in them that aren't found until they're executed (which is done whenever you call `mayday`), the stack trace won't be very helpful in debugging (because there is no source map from the build phase back to your `Maydayfile` code)\n", 'addition_count': 1, 'deletion_count': 1, 'src_file': 'a/README.md', 'tgt_file': 'b/README.md', 'file_extension': '.md', 'before_file': '[![Gem Version](https://badge.fury.io/rb/mayday.svg)](http://badge.fury.io/rb/mayday)\n[![Build Status](https://travis-ci.org/marklarr/mayday.svg?branch=master)](https://travis-ci.org/marklarr/mayday)\n\n\nEasily add custom warnings and errors to your Xcode project\'s build process\n\n## Installation\n```sh\n$ gem install mayday\n```\n\n## Usage\n\nCreate a Maydayfile\n\n```sh\n$ mayday init\n```\n\nAdd some warning and error checks to that file\n\n```ruby\n# Maydayfile\n\n# Required\nxcode_proj "CoolApp.xcodeproj"\n\n# Use regular expressions to define errors or warnings on a line-by-line basis\nerror_regex "Please remove Copyright boilerplate", /^\\/\\/  Copyright \\(c\\).*$/, :files => "*AppDelegate*"\nwarning_regex "TODO", /^\\/\\/\\s+TODO:.*$/\n```\n\nYou can do more advanced checks, too, with blocks\n\n``` ruby\n# Maydayfile\n\nwarning :line, :exclude => "Fixtures/SomeDir/Excluded/*" do |line|\n  line.length > 120 ? "Length of line #{line.length} is longer than 120 characters!" : false\nend\n\n# You can get the whole file, too\nerror :file do |entire_file|\n  max_number_of_lines = 500\n  \n  number_of_code_or_comment_lines = entire_file.split("\\n").select { |line| line.strip.length > 0 }.count\n  if number_of_code_or_comment_lines > max_number_of_lines\n    # Map line numbers to errors\n    { "1" => "File is #{number_of_code_or_comment_lines} lines long" }\n  else\n    false\n  end\nend\n```\n\nWhen you\'re ready, run\n\n```sh\n$ mayday\n```    \n\nNext time you build your project, your errors and warnings will be flagged\n\n![Mayday warnings and errors in Xcode](https://raw.githubusercontent.com/marklarr/mayday/master/docs/example.jpg?token=760261__eyJzY29wZSI6IlJhd0Jsb2I6bWFya2xhcnIvbWF5ZGF5L21hc3Rlci9kb2NzL2V4YW1wbGUuanBnIiwiZXhwaXJlcyI6MTQxNDM5MDIxNH0%3D--e7969b95aea1bc76749ae9226d2ac5ffef0cf322)\n\n![Mayday warnings and errors in Xcode, inline](https://raw.githubusercontent.com/marklarr/mayday/master/docs/example_inline.jpg?token=760261__eyJzY29wZSI6IlJhd0Jsb2I6bWFya2xhcnIvbWF5ZGF5L21hc3Rlci9kb2NzL2V4YW1wbGVfaW5saW5lLmpwZyIsImV4cGlyZXMiOjE0MTQzOTAzMzh9--bc9abbe40843317e7b6a30a9521ebf6ae457ece2)\n\nYou can also run mayday from the command line\n\n```sh\n$ mayday run\n```\n\nYou also have the option to choose the file specifying the project and rules (by default this will be `Maydayfile`) using\n\n```sh\n$ mayday run --rules MyRulesFile\n```\n\nSince Ruby is installed by default on OSX, the warnings and errors will work for anybody building your project, even if they don\'t have RVM, RubyGems, or mayday.\n\n### Options\n\n`warning`, `error`, `warning_regex`, and `error_regex` all accept an options hash with any of the following options\n\n* `language` limits to files in the provided language. Accepts `"swift"` and `"objective-c"`.\n  * `warning :line, :language => "swift" do ...`\n\n## Caveats\n\n* `mayday` uses [sourcify]() to write your custom `warning` and `errors` blocks to a build phase, all [gotchas in sourcify](https://github.com/ngty/sourcify#gotchas) apply to your blocks.\n* `mayday` copies your custom blocks, line for line, into a build phase, so all variables inside of them must be of local scope. Anything defined outside of a custom block will not be included in the build phase.\n* Gems cannot but used inside of custom blocks, only vanilla, system Ruby.\n* If your custom blocks have errors in them that aren\'t found until they\'re executed (which is done whenever you call `mayday`), the stack trace won\'t be very helpful in debugging (because there is no source map from the build phase back to your `Maydayfile` code)\nFor some ideas on how to start using mayday, see the [cookbook](https://github.com/marklarr/mayday/blob/master/docs/Cookbook.md)\n\n## Benchmarking\n\nYou may be concerned about how much overhead this will add to your build process. To see how quickly your `mayday` checks execute, use \n\n```sh\n$ mayday benchmark\n```\n\n## Caveats\n\n* `mayday` uses [sourcify](https://github.com/ngty/sourcify) to write your custom `warning` and `errors` blocks to a build phase, all [gotchas in sourcify](https://github.com/ngty/sourcify#gotchas) apply to your blocks.\n* `mayday` copies your custom blocks, line for line, into a build phase, so all variables inside of them must be of local scope. Anything defined outside of a custom block will not be included in the build phase.\n* Gems cannot be used inside of custom blocks, only vanilla, system Ruby.\n* If your custom blocks have errors in them that aren\'t found until they\'re executed (which is done whenever you call `mayday`), the stack trace won\'t be very helpful in debugging (because there is no source map from the build phase back to your `Maydayfile` code)\n* Generating efficient code to write into the build phase is difficult. The code generated by `MayDay::ScriptGenerator#to_ruby` could definitely be optimized.\n\n## Uninstallation\n\n```sh\n$ mayday down\n```\n\n## Contributing\n\nWe\'d love to see your ideas for improving this library! The best way to contribute is by submitting a pull request. We\'ll do our best to respond to your patch as soon as possible. You can also submit a [new GitHub issue](https://github.com/marklarr/mayday/issues/new) if you find bugs or have questions. :octocat:\n\nPlease make sure to follow our general coding style and add test coverage for new features!\n', 'message': 'Merge pull request #4 from Keithbsmiley/ks-readme-fix\n\nAdd readme link', 'author_name': 'Mark Larsen', 'lang': 'md'}