When defining macros that headers rely on, such as _FILE_OFFSET_BITS
, FUSE_USE_VERSION
, _GNU_SOURCE
among others, where is the best place to put them?
Some possibilities I've considered include
- At the top of the any source files that rely on definitions exposed by headers included in that file
- Immediately before the include for the relevant header(s)
- Define at the
CPPFLAGS
level via the compiler? (such as-D_FILE_OFFSET_BITS=64
) for the:- Entire source repo
- The whole project
- Just the sources that require it
- In project headers, which should also include those relevant headers to which the macros apply
- Some other place I haven't thought of, but is infinitely superior
A note: Justification by applicability to make, autotools, and other build systems is a factor in my decision.
I usually put them as close as practicable to the things that need them, whilst ensuring you don't set them incorrectly.
Related pieces of information should be kept close to make it easier to identify. A classic example is the ability for C to now allow variable definitions anywhere in the code rather than just at the top of a function:
is a lot better than:
since you don't have to go searching for the type of
x
in the latter case.By way of example, if you need to compile a single source file multiple times with different values, you have to do it with the compiler:
However, if every compilation of that file will use 7, it can be moved closer to the place where it's used:
Note that I've done it twice so that it's more localised. This isn't a problem since, if you change only one, the compiler will tell you about it, but it ensures that you know those defines are set for the specific headers.
And, if you're certain that you will never include (for example)
bitio.h
without first settingBITCOUNT
to 8, you can even go so far as to create abitio8.h
file containing nothing but:and then just include
bitio8.h
in your source files.Most projects that I've seen use them did it via
-D
command line options. They are there because that eases building the source with different compilers and system headers. If you were to build with a system compiler for another system that didn't need them or needed a different set of them then a configure script can easily change the command line arguments that a make file passes to the compiler.It's probably best to do it for the entire program because some of the flags effect which version of a function gets brought in or the size/layout of a struct and mixing those up could cause crazy things if you aren't careful.
They certainly are annoying to keep up with.
For
_GNU_SOURCE
and the autotools in particular, you could useAC_USE_SYSTEM_EXTENSIONS
(citing liberally from the autoconf manual here):For
_FILE_OFFSET_BITS
, you need to callAC_SYS_LARGEFILE
andAC_FUNC_FSEEKO
:If you are using
autoheader
to generate aconfig.h
, you could define the other macros you care about usingAC_DEFINE
orAC_DEFINE_UNQUOTED
:The definition will then get passed to the command line or placed in
config.h
, if you're using autoheader. The real benefit ofAC_DEFINE
is that it easily allows preprocessor definitions as a result of configure checks and separates system-specific cruft from the important details.When writing the
.c
file,#include "config.h"
first, then the interface header (e.g.,foo.h
forfoo.c
- this ensures that the header has no missing dependencies), then all other headers.Using header files is what I recommend because it allows you to have a code base built by make files and other build systems as well as IDE projects such as Visual Studio. This gives you a single point of definition that can be accompanied by comments (I'm a fan of doxygen which allows you to generate macro documentation).
The other benefit with header files is that you can easily write unit tests to verify that only valid combinations of macros are defined.
If the macros affect system headers, they probably ought to go somewhere where they affect every source file that includes those system headers (which includes those that include them indirectly). The most logical place would therefore be on the command line, assuming your build system allows you to set e.g. CPPFLAGS to affect the compilation of every file.
If you use precompiled headers, and have a precompiled header that must therefore be included first in every source file (e.g. stdafx.h for MSVC projects) then you could put them in there too.
For macros that affect self-contained libraries (whether third-party or written by you), I would create a wrapper header that defines the macros and then includes the library header. All uses of the library from your project should then include your wrapper header rather than including the library header directly. This avoids defining macros unnecessarily, and makes it clear that they relate to that library. If there are dependencies between libraries then you might want to make the macros global (in the build system or precompiled header) just to be on the safe side.
Global, project-wide constants that are target specific are best put in CCFLAGS in your makefile. Constants you use all over the place can go in appropriate header files which are included by any file that uses them.
For example,
Then, in some other header,