GNOME Bugzilla – Bug 595935
New include handling policy issues warnings
Last modified: 2009-12-30 13:38:52 UTC
Created attachment 143683 [details] Minimal project that shows the problem The attached sample project issues some warnings about undefined macros. The full project is BeRTOS documentation, which can be downloaded from http://download.bertos.org/release/bertos.tar.bz2 Possibly a regression from 1.5.8. In the full project the following compilation warnings are issued: src/bertos/bertos/cfg/macros.h:225: Warning: documentation for unknown define BIT_CHANGE found. src/bertos/bertos/cfg/macros.h:264: Warning: documentation for unknown define BIT_CHANGE_BV found. src/bertos/bertos/cfg/macros.h:327: Warning: documentation for unknown define ROTR found. src/bertos/bertos/cfg/macros.h:339: Warning: documentation for unknown define MAKE_ID found. While the first two are inside a #if/#endif block and I'm looking for a workaround (like PREDEFINES or such), the latter 2 are plain macros defined like this: /** * ROTR documentation here */ #define ROTR [something] The problem is, version 1.5.8 on Ubuntu 9.10 doesn't complain at all and correctly generates documentation for the last 2 macros; also, if I *rename* the file cfg/macros.h to cfg/asdf.h, no warning is issued and documentation is generated as expected even with version 1.6.1. The original project has empty INPUT field. Changing it to: INPUT = bertos/cfg/macros.h bertos/ fixes the problem. Tested on Linux and Windows.
Created attachment 143690 [details] Another test case with a PREDEFINED added
When adding to PREDEFINED the macro COMPILER_VARIADIC_MACROS to generate documentation for BIT_CHANGE and BIT_CHANGE_BV the warnings appear again and the INPUT trick doesn't work.
Turns out this had nothing to do with the new include handling policy, but with a macro containing an empty C style comment, e.g.: #define BIT_MASK_SINGLE__(use_bv, index, max, arg) \ ((index < max) ? (PP_CAT(BIT_EXTRACT_FLAG_, use_bv) arg) : 0) \ /**/ If you remove the /**/ or replace it by /* */ it should work again. Doxygen was treating /** as the start of a special comment and then looked for the */ which might never come. I'll fix the preprocessor's matching rules for this case.
Thanks, it works. Feel free to close the bug when proper rules are implemented.
This bug was previously marked ASSIGNED, which means it should be fixed in doxygen version 1.6.2. Please verify if this is indeed the case and reopen the bug if you think it is not fixed (include any additional information that you think can be relevant).