CPP(1)

πŸ“¦
version 9.5.0 Β· 3 versions
, in ubuntu jammy

✨ cpp ✨

Okay so this is the CPP(1) page from the GNU manual, bestie πŸ’– Let's get into it πŸ¦‹

✨ NAME ✨

cpp β€” The C Preprocessor 🌸

✨ SYNOPSIS ✨

cpp [-Dmacro[=defn]...] [-Umacro]
    [-Idir...] [-iquotedir...]
    [-M|-MM] [-MG] [-MF filename]
    [-MP] [-MQ target...]
    [-MT target...]
    infile [[-o] outfile]

Only the most useful options are shown up top, so check below for the full list of preprocessor-specific options πŸ’…. cpp also takes most gcc driver options, which aren't listed here, so if you want those deets, go read the GCC documentation 🧚.

✨ DESCRIPTION ✨

Okay so the C preprocessor, which everyone calls cpp, is a macro processor. The C compiler uses it automatically to transform your program before compilation even starts πŸ”₯. It's called a macro processor because it lets you define macros, which are brief abbreviations for longer constructs. Iconic behavior, honestly πŸ‘‘.

The C preprocessor is meant to be used only with C, C++, and Objective-C source code. In the past people abused it as a general text processor, but ngl that's not its vibe πŸ’€. It will choke on input that doesn't follow C's lexical rules. For example, apostrophes get read as the start of character constants, and that causes errors 😭. You also can't count on it keeping stuff that doesn't matter to C-family languages. If you preprocess a Makefile, all the hard tabs get removed, and the Makefile won't work.

Warning, bestie: if you run a Makefile through cpp, every hard tab gets stripped out and the Makefile will not work. Do not do this to your Makefile πŸ™ˆ.

Having said that, you can lowkey get away with using cpp on things that aren't C. Other Algol-ish languages are often safe (Ada, etc.), and assembly is okay too, as long as you're careful πŸ¦‹. -traditional-cpp mode keeps more white space and is generally more permissive ✨. A lot of problems go away if you write C or C++ style comments instead of native language comments and keep your macros simple 🫢.

Wherever possible, use a preprocessor built for the language you're writing in πŸ’–. Modern versions of the GNU assembler have macro facilities. Most high level programming languages have their own conditional compilation and inclusion mechanisms. If all else fails, try a true general text processor, like GNU M4 🌈.

C preprocessors vary a little. This manual talks about the GNU C preprocessor, which gives you a small superset of the features of ISO Standard C πŸŽ€. In its default mode, the GNU C preprocessor skips a few things the standard requires. These are features that are rarely, if ever, used, but they can cause surprising changes to the meaning of a program that doesn't expect them πŸ™ˆ. If you want strict ISO Standard C, use -std=c90, -std=c99, -std=c11 or -std=c17, depending on which version of the standard you want. To get all the mandatory diagnostics, you must also use -pedantic πŸ’….

This manual describes how the ISO preprocessor behaves. To cut down on gratuitous differences, wherever the ISO preprocessor doesn't clash with traditional semantics, the traditional preprocessor should act the same way 🧚. The differences that do exist are spelled out in the section Traditional Mode.

For clarity, unless noted otherwise, any mention of CPP in this manual means GNU CPP πŸ’œ.

✨ OPTIONS ✨

The cpp command expects two file names as arguments, infile and outfile. The preprocessor reads infile, along with any other files it pulls in with #include. All the output from the combined input files gets written to outfile πŸ“.

Either infile or outfile can be -. As infile, it means read from standard input. As outfile, it means write to standard output. If either file is left out, it works the same as if - had been given for that file. You can also use the -o outfile option to pick the output file ✨.

Unless otherwise noted, or the option ends in =, every option that takes an argument can have that argument right after the option, or with a space between the option and the argument. So -Ifoo and -I foo have the same effect πŸ’–.

Lots of options have multi-letter names, so you can't group multiple single-letter options together. -dM is very different from -d -M 😭.

  • -D name β€” Predefines name as a macro, with the definition 1 🌸.
  • -D name=definition β€” The contents of definition get tokenized and processed as if they showed up during translation phase three in a #define directive. The definition gets cut off by any embedded newline characters βœ‚οΈ. If you're calling the preprocessor from a shell (or something shell-like), you might need the shell's quoting syntax to protect characters like spaces, since those mean something to the shell 🐚. If you want a function-like macro on the command line, put its argument list in parentheses before the equals sign (if there is one). Parentheses mean stuff to most shells, so quote the option. With sh and csh, -D'name(args...)=definition' works 🧁.
    • -D and -U options get processed in the order they show up on the command line. All -imacros file and -include file options get processed after all the -D and -U options πŸ”₯.
  • -U name β€” Cancels any previous definition of name, whether it was built in or set with a -D option πŸ¦‹.
  • -include file β€” Processes file as if #include "file" appeared as the very first line of the primary source file. The big difference is that the first directory searched for file is the preprocessor's working directory, not the directory with the main source file. If it's not found there, it's searched for in the rest of the usual #include "..." search chain 🧚. If you give multiple -include options, the files get included in the order they appear on the command line πŸ’….
  • -imacros file β€” Exactly like -include, except any output produced by scanning file gets thrown away. The macros it defines stay defined. This lets you grab all the macros from a header without also processing its declarations πŸŽ€. All files given with -imacros get processed before all files given with -include πŸ‘‘.
  • -undef β€” Doesn't predefine any system-specific or GCC-specific macros. The standard predefined macros stay defined πŸ™ˆ.
  • -pthread β€” Defines extra macros needed for using the POSIX threads library 🧡. Use this option consistently for both compilation and linking, bestie. It's supported on GNU/Linux targets, most other Unix derivatives, and also on x86 Cygwin and MinGW targets 🌈.
  • -M β€” Instead of outputting the preprocessed result, this outputs a rule suitable for make that describes the dependencies of the main source file πŸ”₯. The preprocessor outputs one make rule containing the object file name for that source file, a colon, and the names of all the included files. That includes the ones coming from -include or -imacros command-line options πŸ’–. Unless you set it explicitly (with -MT or -MQ), the object file name is the source file's name with any suffix swapped for the object file suffix and with any leading directory parts removed πŸ“. If there are a lot of included files, the rule gets split into several lines using \-newline ✨. The rule has no commands πŸ’….
Heads up: -M doesn't suppress the preprocessor's debug output, like -dM. To keep that debug output from mixing with your dependency rules, specify the dependency output file explicitly with -MF, or use an environment variable like DEPENDENCIES_OUTPUT 😭. Debug output still goes to the regular output stream like normal 🧚.
  • Passing -M to the driver implies -E, and suppresses warnings with an implicit -w πŸ™ˆ.
  • -MM β€” Like -M, but it doesn't mention header files found in system header directories, or header files included (directly or indirectly) from one of those system headers πŸ¦‹. This also means the choice of angle brackets or double quotes in an #include directive doesn't, on its own, decide whether that header shows up in -MM dependency output πŸ’œ.
  • -MF file β€” When used with -M or -MM, this picks a file to write the dependencies to. If you don't give -MF, the preprocessor sends the rules to the same place it would send preprocessed output 🌸. When used with the driver options -MD or -MMD, -MF overrides the default dependency output file πŸ‘‘. If file is -, the dependencies get written to stdout πŸŽ€.
  • -MG β€” Used together with an option like -M that asks for dependency generation, -MG assumes missing header files are generated files. It adds them to the dependency list without raising an error ✨. The dependency filename is taken straight from the #include directive, without any path prepended 🧚. -MG also suppresses preprocessed output, since a missing header file makes that useless πŸ’€. This feature is used in automatic updating of makefiles 🫢.
  • -MP β€” This option tells CPP to add a phony target for each dependency other than the main file, so each one depends on nothing 🌈. These dummy rules work around errors make gives if you remove header files without updating the Makefile to match 😭. This is typical output:
test.o: test.c test.h

test.h:
  • -MT target β€” Changes the target of the rule emitted by dependency generation 🎯. By default, CPP takes the name of the main input file, deletes any directory components and any file suffix like .c, and appends the platform's usual object suffix. That result is the target πŸ¦‹. An -MT option sets the target to be exactly the string you give it. If you want multiple targets, you can put them in a single argument to -MT, or use multiple -MT options πŸ’…. For example, -MT '$(objpfx)foo.o' might give:
$(objpfx)foo.o: foo.c
  • -MQ target β€” Same as -MT, but it quotes any characters that are special to Make πŸ”. -MQ '$(objpfx)foo.o' gives:
$$(objpfx)foo.o: foo.c

The default target gets quoted automatically, as if it had been given with -MQ πŸ’–.

  • -MD β€” -MD is equivalent to -M -MF file, except that -E is not implied πŸ”₯. The driver figures out file based on whether an -o option is given. If it is, the driver uses that argument but with a suffix of .d. Otherwise, it takes the name of the input file, removes any directory components and suffix, and applies a .d suffix 🧁. If -MD is used together with -E, any -o switch is understood to name the dependency output file. But if -MD is used without -E, each -o is understood to name a target object file 🌸. Since -E isn't implied, -MD can generate a dependency output file as a side effect of the compilation process ✨.
  • -MMD β€” Like -MD, except it only mentions user header files, not system header files πŸŽ€.
  • -fpreprocessed β€” okay bestie, this tells the preprocessor "hey, this file is ALREADY preprocessed, don't redo it" πŸ’…βœ¨ It skips macro expansion, trigraph conversion, escaped newline splicing, and processing of most directives πŸ™ˆ It still recognizes and removes comments though, so you can pass a file preprocessed with -C to the compiler without any drama πŸ¦‹ In this mode the integrated preprocessor is literally just a tokenizer for the front ends 🧚

-fpreprocessed is implicit if the input file has one of the extensions .i, .ii or .mi. These are the extensions GCC uses for preprocessed files created by -save-temps 🌸

  • -fdirectives-only β€” handle directives πŸ“œ but do NOT expand macros πŸ™…β€β™€οΈ

The behavior of this one depends on -E and -fpreprocessed, so pay attention πŸ‘€

  • With -E, preprocessing is limited to handling directives like "#define", "#ifdef", and "#error". Other preprocessor operations, like macro expansion and trigraph conversion, are not performed. Also the -dD option is implicitly enabled πŸŽ€
  • With -fpreprocessed, predefinition of command line and most builtin macros is disabled. Macros like "__LINE__", which are contextually dependent, are handled normally. This enables compiling files previously preprocessed with "-E -fdirectives-only" ✨
  • With both -E and -fpreprocessed, the rules for -fpreprocessed take precedence. This enables full preprocessing of files previously preprocessed with "-E -fdirectives-only" πŸ‘‘
  • -fdollars-in-identifiers β€” lets you use $ in identifiers πŸ’–
  • -fextended-identifiers β€” accepts universal character names in identifiers 🌈 This one is enabled by default for C99 (and later C standard versions) and C++, so you basically don't have to ask πŸ’…
  • -fno-canonical-system-headers β€” when preprocessing, this stops system header paths from getting shortened with canonicalization 🫢
  • -ftabstop=width β€” sets the distance between tab stops πŸ“ This helps the preprocessor report correct column numbers in warnings or errors, even if tabs show up on the line πŸ™Œ If the value is less than 1 or greater than 100, the option is ignored. The default is 8 πŸ“
  • -ftrack-macro-expansion[=level] β€” tracks where tokens are across macro expansions πŸ•΅οΈβ€β™€οΈ This lets the compiler show the current macro expansion stack when a compilation error happens inside a macro expansion, which is SO helpful. The catch? Using it makes the preprocessor and the compiler eat more memory πŸ” The level parameter lets you pick how precise the token location tracking is, so you can cut down on memory if you need to. Level 0 turns this option off πŸ™…β€β™€οΈ Level 1 tracks token locations in a degraded mode for minimal memory overhead; in this mode, all tokens resulting from the expansion of an argument of a function-like macro have the same location. Level 2 tracks token locations completely, and it is the MOST memory hungry option πŸ’€ If you give this option no argument, the default parameter value is 2 πŸ”₯

Note that -ftrack-macro-expansion=2 is activated by default πŸ‘‘

  • -fmacro-prefix-map=old=new β€” when preprocessing files living in the directory old, it expands the __FILE__ and __BASE_FILE__ macros as if those files lived in directory new instead πŸ—ΊοΈ You can use . for new to change an absolute path into a relative one, which can lead to more reproducible, location-independent builds πŸ¦‹ This option also affects __builtin_FILE() during compilation. See also -ffile-prefix-map 🧚
  • -fexec-charset=charset β€” sets the execution character set, which is used for string and character constants πŸ’¬ The default is UTF-8. charset can be any encoding supported by the system's iconv library routine 🌸
  • -fwide-exec-charset=charset β€” sets the wide execution character set, used for wide string and character constants 🌍 The default is UTF-32 or UTF-16, whichever matches the width of wchar_t. Just like -fexec-charset, charset can be any encoding supported by the system's iconv library routine πŸ’–
Heads up: you will have problems with encodings that do not fit exactly in wchar_t 😭
  • -finput-charset=charset β€” sets the input character set, which is used for translating from the input file's character set to the source character set GCC uses πŸ“₯ If the locale doesn't specify one, or GCC can't get that info from the locale, the default is UTF-8. This can be overridden by either the locale or this command-line option. Right now the command-line option takes precedence if there's a conflict πŸ‘‘ charset can be any encoding supported by the system's iconv library routine 🫢
  • -fworking-directory β€” turns on linemarkers in the preprocessor output so the compiler knows the current working directory at the time of preprocessing πŸ“ When this is enabled, the preprocessor emits, after the initial linemarker, a second linemarker with the current working directory followed by two slashes. GCC uses this directory (if it's in the preprocessed input) as the working directory in some debugging information formats πŸ› This option is implicitly enabled if debugging information is enabled, but you can stop it with the negated form -fno-working-directory πŸ™…β€β™€οΈ If the -P flag is in the command line, this option has no effect, since no #line directives get emitted whatsoever 😭
  • -A predicate=answer β€” makes an assertion with the predicate predicate and the answer answer πŸŽ€ This form is preferred over the older -A predicate(answer) form, which is still supported, because it doesn't use shell special characters 🐚
  • -A -predicate=answer β€” cancels an assertion with the predicate predicate and the answer answer 🚫
  • -C β€” do NOT discard comments πŸ’¬ All comments get passed through to the output file, EXCEPT comments in processed directives, which get deleted along with the directive πŸ—‘οΈ
Be prepared for side effects when using -C! It makes the preprocessor treat comments as tokens in their own right. For example, comments at the start of what would be a directive line turn that line into an ordinary source line, since the first token on the line is no longer a # πŸ’€
  • -CC β€” do not discard comments, INCLUDING during macro expansion 🌈 This is like -C, except comments contained within macros also get passed through to the output file where the macro is expanded 🧚

In addition to the side effects of -C, the -CC option converts all C++-style comments inside a macro into C-style comments. This is to stop a later use of that macro from accidentally commenting out the rest of the source line πŸ™ˆ -CC is generally used to support lint comments 🧹

  • -P β€” inhibits generating linemarkers in the preprocessor output πŸš«πŸ“ This might be useful when running the preprocessor on something that isn't C code and is going to a program that might get confused by the linemarkers 🌸
  • -traditional, -traditional-cpp β€” try to imitate pre-standard C preprocessors, instead of ISO C preprocessors πŸ•°οΈ

GCC doesn't otherwise try to emulate a pre-standard C compiler, and these options are only supported with the -E switch, or when invoking CPP explicitly πŸ™ƒ

  • -trigraphs β€” supports ISO C trigraphs πŸ”Ί These are three-character sequences, all starting with ??, that ISO C defines to stand for single characters. For example, ??/ stands for \, so '??/n' is a character constant for a newline πŸ“

By default GCC ignores trigraphs, but in standard-conforming modes it converts them. See the -std and -ansi options πŸ‘‘

  • -remap β€” enables special code to work around file systems that only allow super short file names, like MS-DOS πŸ’Ύ
  • -H β€” prints the name of each header file used, on top of your other normal stuff πŸ“š Each name is indented to show how deep it is in the #include stack πŸͺœ Precompiled header files get printed too, even if they turn out to be invalid. An invalid precompiled header file is printed with ...x and a valid one with ...! βœ…βŒ
  • -dletters β€” tells the compiler to make debugging dumps as specified by letters πŸ” The flags documented here are the ones relevant to the preprocessor. Other letters are interpreted by the compiler proper, or reserved for future versions of GCC, and get silently ignored 🀫
If you specify letters whose behavior conflicts, the result is undefined. Undefined means anything can happen, bestie, so maybe don't πŸ’€
  • -dM β€” instead of the normal output, generates a list of #define directives for all the macros defined during the execution of the preprocessor, including predefined macros πŸ“‹ This is a way to find out what's predefined in your version of the preprocessor 🧐 Assuming you have no file foo.h, the command below shows all the predefined macros:
touch foo.h; cpp -dM foo.h
  • -dD β€” like -dM, except in two ways: it does NOT include the predefined macros, and it outputs both the #define directives AND the result of preprocessing πŸŽ€ Both kinds of output go to the standard output file πŸ“€
  • -dN β€” like -dD, but only emits the macro names, not their expansions 🏷️
  • -dI β€” outputs #include directives in addition to the result of preprocessing πŸ“¦
  • -dU β€” like -dD, except only macros that get expanded, or whose definedness gets tested in preprocessor directives, are output 🎯 The output is delayed until the use or test of the macro, and #undef directives are also output for macros that were tested but undefined at the time πŸ¦‹
  • -fdebug-cpp β€” this one is ONLY useful for debugging GCC πŸ› οΈ When used from CPP or with -E, it dumps debugging information about location maps. Every token in the output is preceded by the dump of the map its location belongs to πŸ—ΊοΈ

When used from GCC without -E, this option has no effect πŸ™ƒ

  • -I dir, -iquote dir, -isystem dir, -idirafter dir β€” adds the directory dir to the list of directories searched for header files during preprocessing πŸ“‚βœ¨

If dir begins with = or $SYSROOT, then the = or $SYSROOT gets replaced by the sysroot prefix. See --sysroot and -isysroot πŸ§šπŸ’œ

Okay so bestie, directories given with -iquote only apply to the quote form of the directive, #include "file". Directories given with -I, -isystem, or -idirafter apply to lookup for both #include "file" and #include <file> 🫢

You can throw any number or combo of these options on the command line to search for header files in several directories at once πŸ“‚βœ¨ Here's the lookup order, and it's giving very organized:

  1. For the quote form of the include directive, the directory of the current file gets searched first.
  2. For the quote form, the directories given by -iquote options get searched left-to-right, in the order they show up on the command line.
  3. Directories given with -I options get scanned left-to-right.
  4. Directories given with -isystem options get scanned left-to-right.
  5. Standard system directories get scanned.
  6. Directories given with -idirafter options get scanned left-to-right.

You can use -I to override a system header file and swap in your own version, since these directories get searched before the standard system header file directories πŸ”„ But don't use this option to add directories that hold vendor-supplied system header files. Use -isystem for that πŸ™…β€β™€οΈ

The -isystem and -idirafter options also mark the directory as a system directory, so it gets the same special treatment as the standard system directories πŸ‘‘

If a standard system include directory, or a directory given with -isystem, is also given with -I, the -I option is ignored. The directory still gets searched, but as a system directory at its normal spot in the system include chain. This is so GCC's procedure to fix buggy system headers and the ordering for the #include_next directive don't get accidentally changed πŸ₯Ί If you really need to change the search order for system directories, use the -nostdinc and/or -isystem options.

  • -I- β€” Split the include path πŸ’” This one is deprecated, so please don't reach for it. Use -iquote instead for -I directories before the -I-, and remove the -I- option.
⚠️ Deprecated alert! -I- is deprecated. Use -iquote instead for -I directories before the -I-, and remove the -I- option.

Any directories given with -I options before -I- only get searched for headers requested with #include "file". They are not searched for #include <file>. If extra directories are given with -I options after the -I-, those directories get searched for all #include directives. Also, -I- stops the directory of the current file from being used as the first search directory for #include "file", and there is no way to override that effect of -I- πŸ™…β€β™€οΈ

  • -iprefix prefix β€” Set prefix as the prefix for subsequent -iwithprefix options. If the prefix represents a directory, include the final / πŸ“
  • -iwithprefix dir, -iwithprefixbefore dir β€” Tack dir onto the prefix you set earlier with -iprefix, and add the resulting directory to the include search path. -iwithprefixbefore puts it in the same place -I would, while -iwithprefix puts it where -idirafter would 🧚
  • -isysroot dir β€” This one is like the --sysroot option, but it only applies to header files (except for Darwin targets, where it applies to both header files and libraries). See the --sysroot option for more information 🌈
  • -imultilib dir β€” Use dir as a subdirectory of the directory containing target-specific C++ headers πŸ“
  • -nostdinc β€” Don't search the standard system directories for header files. Only the directories explicitly given with -I, -iquote, -isystem, and/or -idirafter options (and the directory of the current file, if appropriate) get searched πŸ™ˆ
  • -nostdinc++ β€” Don't search the C++-specific standard directories, but do still search the other standard directories. (This option is used when building the C++ library.) πŸ’œ
  • -Wcomment, -Wcomments β€” Warn whenever a comment-start sequence /* appears in a /* comment, or whenever a backslash-newline shows up in a // comment. This warning is enabled by -Wall πŸ‘€
  • -Wtrigraphs β€” Warn if any trigraphs are encountered that might change the meaning of the program. Trigraphs within comments don't get warned about, except those that would form escaped newlines. This option is implied by -Wall. If -Wall isn't given, this option is still enabled unless trigraphs are enabled. To get trigraph conversion without warnings, but still get the other -Wall warnings, use -trigraphs -Wall -Wno-trigraphs 🫠
  • -Wundef β€” Warn if an undefined identifier is evaluated in an #if directive. Such identifiers get replaced with zero πŸ”
  • -Wexpansion-to-defined β€” Warn whenever defined is encountered in the expansion of a macro (including the case where the macro is expanded by an #if directive). Such usage is not portable. This warning is also enabled by -Wpedantic and -Wextra 🚫
  • -Wunused-macros β€” Warn about macros defined in the main file that are unused. A macro counts as used if it's expanded or tested for existence at least once. The preprocessor also warns if the macro hasn't been used by the time it's redefined or undefined. Built-in macros, macros defined on the command line, and macros defined in include files don't get warned about 🧹
Note: If a macro is actually used, but only used in skipped conditional blocks, then the preprocessor reports it as unused. To avoid the warning in that case, you might improve the scope of the macro's definition by, for example, moving it into the first skipped block. Alternatively, you could provide a dummy use with something like:
#if defined the_macro_causing_the_warning
#endif
  • -Wno-endif-labels β€” Don't warn whenever an #else or an #endif is followed by text. This sometimes happens in older programs with code of the form πŸ•°οΈ
#if FOO
...
#else FOO
...
#endif FOO

The second and third FOO should be in comments. This warning is on by default.


✨ ENVIRONMENT ✨

This section is all about the environment variables that change how CPP operates πŸ’… You can use them to specify directories or prefixes to use when searching for include files, or to control dependency output.

Note that you can also specify places to search using options such as -I, and control dependency output with options like -M. These take precedence over environment variables, which in turn take precedence over the configuration of GCC πŸ‘‘

CPATH, C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, OBJC_INCLUDE_PATH

Each variable's value is a list of directories separated by a special character, much like PATH, in which to look for header files. The special character, PATH_SEPARATOR, is target-dependent and determined at GCC build time. For Microsoft Windows-based targets it is a semicolon, and for almost all other targets it is a colon 🧩

CPATH specifies a list of directories to be searched as if specified with -I, but after any paths given with -I options on the command line. This environment variable is used regardless of which language is being preprocessed 🌸

The remaining environment variables only apply when preprocessing the particular language they're named for. Each one specifies a list of directories to be searched as if specified with -isystem, but after any paths given with -isystem options on the command line.

In all these variables, an empty element instructs the compiler to search its current working directory. Empty elements can appear at the beginning or end of a path. For instance, if the value of CPATH is ":/special/include", that has the same effect as -I. -I/special/include 🫢

DEPENDENCIES_OUTPUT

If this variable is set, its value specifies how to output dependencies for Make based on the non-system header files processed by the compiler. System header files are ignored in the dependency output πŸ™ˆ

The value of DEPENDENCIES_OUTPUT can be just a file name, in which case the Make rules are written to that file, guessing the target name from the source file name. Or the value can have the form file target, in which case the rules are written to file file using target as the target name πŸ“

In other words, this environment variable is equivalent to combining the options -MM and -MF, with an optional -MT switch too ✨

SUNPRO_DEPENDENCIES

This variable is the same as DEPENDENCIES_OUTPUT (see above), except that system header files are not ignored, so it implies -M rather than -MM. However, the dependence on the main input file is omitted πŸ¦‹

SOURCE_DATE_EPOCH

If this variable is set, its value specifies a UNIX timestamp to be used in replacement of the current date and time in the __DATE__ and __TIME__ macros, so that the embedded timestamps become reproducible ⏰

The value of SOURCE_DATE_EPOCH must be a UNIX timestamp, defined as the number of seconds (excluding leap seconds) since 01 Jan 1970 00:00:00 represented in ASCII. It's identical to the output of date +%s on GNU/Linux and other systems that support the %s extension in the date command πŸ’œ

The value should be a known timestamp, such as the last modification time of the source or package, and it should be set by the build process πŸ› οΈ


✨ SEE ALSO ✨

gpl(7), gfdl(7), fsf-funding(7), gcc(1), and the Info entries for cpp and gcc πŸ“š


Copyright (c) 1987-2019 Free Software Foundation, Inc. πŸŽ€

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation. A copy of the license is included in the man page gfdl(7). This manual contains no Invariant Sections. The Front-Cover Texts are (a) (see below), and the Back-Cover Texts are (b) (see below).

(a) The FSF's Front-Cover Text is:

A GNU Manual

(b) The FSF's Back-Cover Text is:

You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development.

That's a wrap on CPP(1), bestie! πŸ’– Huge thanks to gcc-9 πŸ¦‹ for this one, last touched on 2022-05-27 🌸 Now go preprocess something iconic, you absolute legend πŸ‘‘πŸ’…

πŸ“¦ where this page comes from