I'd like for the clang-format to check that each of my headers have the proper include guard.
For example, for the file dopelib/dopestuff/whatitisyo.h, I'd like the code to be formatted like this:
#ifndef DOPELIB_DOPESTUFF_WHATITISYO_H
#define DOPELIB_DOPESTUFF_WHATITISYO_H
/** Code here. **/
#endif // DOPELIB_DOPESTUFF_WHATITISYO_H
Can clnag-format check this structure and make sure that the include guard is there and that it is named appropriately with the file name in the #ifndef (sort of what cpplint does)?
As far as I know, clang-format doesn't currently support this.
However, you can do exactly this with clang-tidy (documented here). Invoke it like this:
clang-tidy -checks='-*,llvm-header-guard' -fix-errors myIncludeFile.h
Explanation:
The -* tells clang-tidy to disable all checks
The llvm-header-guard tells clang-tidy to enable the check which deals with include guards (documented here)
The -fix-errors tells clang-tidy to fix any resulting issues, even if it runs into other errors parsing the file
The llvm-header-guard expected format of the include-guards is exactly what you requested above; for example the file mydir/myfile.h would use MYDIR_MYFILE_H. I don't see any documentation which actually specifies that this is the format it uses, but I've verified at least version 6.0.0 does use that format.
Also see: clang include fixer, which does something similar.
The accepted solution may not work if
The project has a different file structure
Uses some extensions that clang does not understand
I have a script here: https://github.com/milasudril/texpainter/blob/master/devtools/include_guard_fix.py
Related
Where can I see the actual key-value pairs set in Google style? I can't find the definition in the clang repository.
They can be found in the Format.cpp file of the clang lib.
https://github.com/llvm/llvm-project/blob/04ee232ff212b6c308e2ebc7b6125892681c54ae/clang/lib/Format/Format.cpp#L660
This is the start of the LLVM style, then the following functions after it hold the other pre-defined configuration settings. If you are looking at a different version of the code base, look for the function 'getPredefinedStyle' to find the sub-calls that are used based on the style chosen.
I am trying to parse c-clang index.h file with ClangSharp (just for testing purposes of ClangSharp parser on C#) and I found that it misses parsing of functions because of CINDEX_LINKAGE macro in the function declaration.
If I remove it, parser will correctly find FunctionDecl and parse it without errors.
I cannot understand how this macro preventing functions from being parsed. Does someone know how to workaround this?
Issue was in the #include line itself. By default, clang header includes setup to search in the directory on one level up, but clang itself by some reason does not understand such
include format.
What I want to find is the existence of some platform specific header file.
For example, in source code there will be some #ifdef section like this.
#ifdef HAVE_XXX_H
//...do something
#else
//...do other thing
#endif
In Autoconf or Cmake, there exists dedicated macro or command for detecting platform specific header file or definition. So, I can easily set 'HAVE_XXX_H' as 1 or 0 according to the result of that macro.
Using bazel, how can I achieve this kind of thing?
Thanks.
If you are sure that the header is always present on a particular platform, use select() as elaborated by László.
If you actually need to detect the header at the build time, you will have to implement a custom repository_rule that will query the system and will generate a workspace with a header defining the macro.
You can use select().
Example: select() in cc_library.srcs. You can do the same in cc_library.hdrs.
I'm developing a C/C++ library that uses ImageMagick (using/supporting both libMagickCore and libMagick++), for reading and writing image data (not for processing).
Now, I would also like to support IM's GraphicsMagick fork (e.g. using Debian's graphicsmagick-libmagick-dev-compat package).
Unfortunately, the APIs have diverged enough, so that I cannot use one as a drop-in replacement of the other. Since they are still quite similar, I plan to use a number of #ifdefs for the API specific parts.
Now my problem is, that it seems quite complicated to detect which API is actually used via pre-processor directives, right after including the generic header (which is called the same for both variants).
Basically, I'm looking for something like a #define (provided by the IM/GM headers) that can be used to tell the two APIs apart. Something like:
#include <Magick++.h>
#ifdef GRAPHICSMAGIC_DEFINE
// GM-specific code
#else
// IM-specific code
#endif
or, for the C-API:
#include <magick/MagickCore.h>
#ifdef GRAPHICSMAGIC_DEFINE2
/* GM-specific code */
#else
/* IM-specific code */
#endif
Ideas?
Autoconf, or CMake.
Really - there's no simpler way around it, but you need to package your solution with something that will ask the system what library is present, and will then generate config.h with the correct pre-processor definitions.
The difference between GraphicsMagick & ImageMagick seem simple enough to do something clever, BUT now that we're a year into the release of IM 7, we now need to check which version & adjust definitions as needed. For example
// IM 6
#include <magick/MagickCore.h>
// IM 7
#include <MagickCore/MagickCore.h>
I would suggest reviewing existing m4 scripts used by other projects available online.
So back to the original question, the generic include headers my look something like this... (and I quote from Imagick library, but can be expanded to cover GM)
#if defined (IM_MAGICKWAND_HEADER_STYLE_SEVEN)
# include <MagickWand/MagickWand.h>
#elif defined (IM_MAGICKWAND_HEADER_STYLE_OLD)
# include <wand/magick-wand.h>
#else
# include <wand/MagickWand.h>
#endif
This isn't really clearly documented, but a shallow search reveals that RIM's RAPC compiler does support preprocessor statements (with some project file modification).
We've been using the simple #ifdef, #else, and #endif directives for quite some time now, as supporting platforms 4.1 through 4.7 with one code base is nearly impossible without them, but I began wondering recently if there are other supported directives which aren't quite as well documented; something akin to C's #elif for example, or even rudimentary equivalency directives?
Here's a complete listing of commands for the RAPC preprocessor. The preprocessor's not very robust, but that's on purpose.
//#preprocess - Used to specify that the file should be preprocessed. It must be the first line of the file.
//#implicit tag - This needs to be on the second line of the file. If tag is part of the command line, then the whole file should be compiled. If not, then it should be excluded.
Then there's the //#ifdef tag ... #else ... #endif and the //#ifndef tag ... #else ... #endif directives that you mentioned.
Also note, there is no nesting of preprocessed blocks and no macros.
RIM Help Center Doc:
http://docs.blackberry.com/en/developers/deliverables/21065/Specifying_preprocessor_directives_657636_11.jsp