Skip to content
Commits on May 26, 2011
  1. Fixed Xcode integration warnings and errors full paths handling. Fixes

    To allow Xcode properly open the file after selecting the warning in build list, it requires full path to it in the output, so I had to add full path to GBSourceInfo and use that when generating Xcode compatible log.
    Note that I had appledoc crashed inside `[GBLog logFormatterForLogFormat]` when using standard log formats. The problem was with sending the given format instance `lowercaseString` however in case numerical value was used, the actual instance was `NSNumber`. To compensate, additional check was added to make sure the instance is indeed a `NSString`. Strange no one reported this as I didn't touch this code since last pushing to GitHub (or everyone was hardly waiting for Xcode compatibility and are now using that mode :).
    Also added `xcode` log format option to help output and increased build number to 701.
Commits on May 25, 2011
  1. Implemented better Xcode integration for warnings and errors. Closes #…

    By using special log format `--logformat xcode`, appledoc formats warnings and errors related to source files in a way that Xcode is able to catch them and display them in build results. Currently only warnings are using that format (there is no error log message related to source files).
    *Implementation details:* Note that implementation required tweaking Cocoa Lumberjack source. Specifically, it required passing in original source code filename and line number to log message. Although logging macros pick up source file and line automatically through `__FILE__` and `__LINE__`, these belong to appledoc sources. But for Xcode warnings making sense, we need to write the file name and line of the context being parsed. To reuse existing macros, I added both values to DDMessage and additional class method to DDLog which needs to be called prior to logging. The method will simply store info to static vars. Then logging method will pick up stored values, write them to message and reset static vars. When emitting log messages, Xcode formatter will check if these values are set and emit specially formatted logs, otherwise it will revert to message only.
    *Additional note:* Although I searched for all occurrences of `GBLogWarn` and `GBLogError` in the project and updated those that seemed relevant, some may have been left out - let me know about exact messages and I will check it. Also note that parsing code currently doesn't emit warnings, if something goes wrong, exceptions are raised, which doesn't log the file and line. Didn't take much time to go into this as these usually indicate parsing code needs to be refined.
Commits on May 10, 2011
Commits on May 9, 2011
  1. Restructured exit codes handling, attempting to tackle #102.

    Exit codes are now better structured to domains and error codes. Also added a debug log statement (available with `--verbose 6` switch) at the end of the run to log the exit code as "seen" by the application.
Commits on May 3, 2011
  1. Implemented exit values different from 0 in case a warning, error or …

    …fatal message is logged. Closes #100.
    Exit values are:
    - 501 for warning
    - 502 for error (this would usually result in exception with exit code 1 anyway).
    - 503 for fatal (not used in appledoc at this point, but anyway)
    This also updates build number to 687.
Commits on Dec 2, 2010
  1. Refactored GBTask to allow continuous reporting of received output an…

    …d error.
    This allows users see progress while indexing large documentation sets for example.
Commits on Nov 28, 2010
  1. Updated CocoaLumberjack to latest version.

    This brought along several modifications to the logging interface.
Commits on Nov 14, 2010
  1. Copied all the changes from the old generating branch.

    Something broke while copying the project over from the old computer, so the simplest way to fix this was to pull from GitHub and copy all the files from the local backup...
Commits on Jul 28, 2010
  1. Added NSError logging option and changed error handling code to log a…

    …nd continue with what is possible instead of raising exception.
Commits on Jul 27, 2010
Commits on Jul 23, 2010
  1. Added some code documentation.

  2. Implemented various logging formats with increasing verbosity.

    This, coupled with verbose argument can produce really helpful debugging output.
Commits on Jul 22, 2010
  1. Implemented logging system initialization and command line arguments …

    …handling for output verbosity.
  2. Added logging framework files.

Something went wrong with that request. Please try again.