You can clone with
HTTPS or Subversion.
If this has already been answered or asked before, I apologize, but a quick search for "xcode warnings" hasn't really dug up much. Anyways, I am sure this is a configuration problem on my own, but I can't figure it out how to make it correctly.
What I want to do is to run appledoc and have it log everything it finds that isn't documented out so that XCode can pick it up when started using an Aggregate.
I managed to make appledoc working and producing happily documentation with this run script in the aggregate:
if [ -e "/usr/local/bin/appledoc" ]
/usr/local/bin/appledoc --create-html --install-docset --project-name "RMTXKit" --project-company "ABACUS Research AG" --company-id "ch.abacus" --output "/Users/misteli/dev/objc/iPhone/Libraries/RMTXKit/Documentation" --publish-docset –logformat=xcode --verbose xcode --keep-undocumented-objects --keep-undocumented-members --keep-intermediate-files --warn-undocumented-object --warn-undocumented-member --warn-empty-description --warn-unknown-directive --merge-categories --merge-category-comment --search-undocumented-doc --warn-missing-arg --no-repeat-first-par --no-warn-invalid-crossref --ignore "*.m" --ignore "*Test.h" --ignore "*Tests.h" --exit-threshold 2 --docset-package-url "http://www.abacus.ch/docs" --docset-feed-url "http://www.abacus.ch/docs" /Users/misteli/dev/objc/iPhone/Libraries/RMTXKit
I experimented around using the $(PROJECTNAME) variables and more, but for the sake of being able to quickly run it in the console, this current version doesn't use that.
So.. this builds up all my documentation but it doesn't log anything that isn't documented. Also, if I simply copy/paste the call to a console, appledoc happily runs, creates the documentation but whilst its running it doesn't log anything out other than its version and build number.
What did I forget to add?
It was a while since I was in this part of the project, so answering from memory. It might be --keep-undocumented-xxxx options that prevent logging out stuff, did you try using your cmd line without them?
Yup, tried that too, but no warnings. I'm using appledoc 2.1, build 858. I'm quiet sure it has something to do with any of my switches cancelling each other or so, but I can't find what it is.
I think I found it.. if I use
it doesn't log anything. If I use
it seems to work though. I remember that some times before when I stumbled the first time over appledoc, there was a wonderful site with descriptions on various tags and how they look in the generated documentation. I don't remember if the valid switches were explained as well, but did that link sink forever or is it planned to have it online again one time?
@robvdveer funny enough, but your version of the command line parameters indeed work correctly. What I'm wondering is why mine don't (--verbose xcode vs --verbose 2 when I use my version of the script). Anways.. will change to your version and adopt parameters accordingly as how I need them. Thanks!
Uhm.. btw.. well.. I can add an issue, but I don't really know what for. I mean.. is this a bug in the command line parsing code of appledoc (no offense but I found that snippet pretty weird to understand) or can you see something wierd in my version of the script?
@robvdveer Well yes, but isn't this here already an open issue or do you want me to close this one and open a separate one for the --verbose flag?
Added fix for invalid verbose level setting, refers to issue #389
It looks like the fix for that problem surfaced my issue. I guess the proper plist type for the --version property is String since the appledoc help indicates that "xcode" is a possible value:
--verbose Log verbosity level [0-6,xcode]
But the example AppledocSettings.plist file shows verbose as a Number.
So I'm thinking that anyone using the sample is going to fail.
Took a look again at the code change. I'm fairly confident that the code change has a bug. You should be able to reproduce the problem by using the example AppledocSettings.plist in the distribution. Since the data type for the '--verbose' flag property is Integer, and the code assumes that self.verbose is a String, it blows up on line 380:
if ([[NSScanner scannerWithString:self.verbose] scanInt:NULL] == false)
self.verbose is declared in GbAppleDocApplication as NSString (https://github.com/tomaz/appledoc/blob/master/Application/GBAppledocApplication.m)
@property (assign) NSString *verbose;
Therefore the test is correct.It has always been a string, and my patch merely verifies that the string is numeric in any way. Perhaps i missed a bit, but i surely tested it. Later on, this string is passed into the logger
All these definitions have not been touched for a long while.
Fair enough. But using the example AppledocSettings.plist from the distribution crashes. I'm thinking this is a problem that should somehow be fixed.
The code before your change allowed a --verbose Integer type in the plist file. Now it crashes.
Perhaps I'm wrong, but I don't know how a test could have been run with the example AppledocSettings.plist and a crash not observed.
The example plist could be changed, but everyone who has already created a customized AppledocSettings.plist will crash until they change the data type of the --verbose property to String. Unfortunately, detecting that this is the cause is fairly involved - I had to debug through the source to see the problem.
So, someone could remove or alter your fix. Or force people to update their AppledocSettings.plist files (and change the example one). It's one or the other. For me, I chose the easy way - update my AppledocSettings.plist.
Btw, I'm still confused. Is "xcode" no longer a valid value for the --verbose flag? Is the documentation wrong or the code?
Set to fix this but would need to convert the project to ARC first...
Should be fixed with latest update.
Closing the issue - seems to be allright now? Feel free to reopen otherwise!