Fred's firmware development diary comments thread

[Fred]

Well done! The commit looks good at a glance except that you aren't you. I'm going to be a stickler and get you to recommit the change such that it is done with your name on it. When you push again, you'll have to --force to over-write the last one (and change history). Currently it comes up as "unknown" or something. It should have your name and email attached. Let me know when you suss that out (.gitconfig change) and I'll drag it into mine :-)

Fred.

[Fred]

http://github.com/fredcooke/freeems-van ... its/master

Congratulations, your first direct contribution to the firmware :-)

Fred.

[jharvey]

I'm dubbing with these flags in the Doxyfile, but so far not dice about the macro thing.

MACRO_EXPANSION = YES
EXPAND_ONLY_PREDEF = NO
SKIP_FUNCTION_MACROS = NO

From what I've read, I think I should be expecting it to expand InjectorXISR, but it hasn't so far. Any how just FYI, with luck I'll figure it out.

[Fred]

I saw your change to the path in the file, why? To me it makes sense to just enter the project dir, then generate the thing by referencing docs/Doxyfile and having the URL already in a browser from the last attempt.

Good work on the other doxy shlt, keep it up.

I've got more changes on the way myself, but they shouldn't conflict anyway :-)

You can always rebase at your end to keep the merges as pure fast forwards for me.

Fred.

[jharvey]

I wonder, are we seeing this differently because I was in the dir with the Doxyfile? I ran it like this "doxywizard Doxyfile" Perhaps you run it like this "doxygen ./docs/Doxyfile"? if so not a big deal I can go either way. It hadn't occurred to me that it would be different if run from a different dir.

injectorISR.c under inc folder?

No luck with Macro expansion. As far as I can tell, these macros are simple compared to what it should be able to do. I'm not sure whey Doxygen is buggering it. It keeps grabbing the header prototype definition, not the expanded macro. It should expand the macro before sending it to the parser, so it should see it as normal code. This means that other code with the declaration line like that might also have an issue with doc generation.

I tried with both Doxygen 1.5.7 and 1.6.1 and no dice. Time for bed.

[jharvey]

I've tried a bunch of this for macro expansion stuff noted here, but still no dice.

http://osdir.com/ml/text.doxygen.genera ... 00035.html

[Fred]

I ran it like this "doxywizard Doxyfile" Perhaps you run it like this "doxygen ./docs/Doxyfile"? if so not a big deal I can go either way.

Yep, exactly, glad you're fine with it as is :-) Of course, you can make that change locally if you prefer it and just never commit it and never push it. Git stash could be your friend in this case :-)

Keep up the good work :-)

It could be that you need to actually change the doxy tags and comments etc to make it work right. Feel free to experiment all you like, git reset --hard HEAD is only a a command away. If you're planning on committing stuff and pushing it up, please communicate with me first so you don't have to keep doing push --force to clear up your online repo.

Fred.

[jharvey]

I think this link holds the key to allow expanding the injector include statements with Doxygen.

http://www.doxygen.nl/commands.html#cmdinclude

However, in my test file currently listed like this,

Code: Select all

/** \file tempISRs.c
 *  A brief tempISR brief desc.
 *  A less brief description for tempISR.
 *  \brief tempISR brief desc.
 */

/** \include injectorISR.c
 */

some text

Under the doxygen generated html code for this file, I only get two lines, while I was hoping to see the code found in that file. The brief description and file commands appear to be working, so I think the links are correct. Also I have a copy of injectorISR.c in this directory, and I have added this directory to the EXAMPLE_PATH config in doxywizard. So I think it should be easily found. However, this is what I get.

Code: Select all

00001 
00010 some text

It appears to be completely ignoring the include command. It could be as simple as it's not looking in the correct directory, however, the log viewer doesn't produce any errors or warnings. I also tried a bogus include file, and it didn't produce any errors or warnings. So it would appear it's OK with ignoring it if it has a problem.

[Fred]

Keep up the research :-) Your two good changes are merged in and pushed up (I rebased my work from today onto them). Great to have good work coming in from others. And thanks to git, so fcuking easy to do, too! :-)

Fred.

[jharvey]

I found this fellow claims he got the @include thing to work.

http://old.nabble.com/Problems-resolvin ... 50671.html

However, I just can't seem to get it to include. I've tried an absolute link like this fellow noted. I've also tried including the file name with an absolute path in the example path field. I'm flying blind about how to isolate what the problem is. I see this fellow was using 1.5.5, I see Fred's posted doxy files are 1.5.6, perhaps I should send the files to Fred and see if the documentation is out of date for the 1.6.1 version I'm running. Any one know how to search the SF mailing lists? Perhaps someone there has posted about the "include command".