Does there exists a flag that I can pass to one of these preprocessors that causes the preprocessor to not resolve any macros in the code? I"m trying to use it just to concatenate any included header files into one file. Thanks!
From the manual
-fdirectives-only
When preprocessing, handle directives, but do not expand macros.
Read the full entry for complete details.
Add the -P option to suppress #line directives, e.g.
g++ -E -P -fdirectives-only ... file.cpp
or:
cpp -P -fdirectives-only ... file.cpp
AFAIK there is no such flag. If you only want to concatenate header files - go ahead and write a short program for this.
You may anyway need sch program as the preprocessor does more than including headers and extending macros. It is also responsible e.g. for concatenating string literals, so e.g. "This""And""That" is turned into "ThisAndThat". So you will get some unexpected changes in your sources anyway.
Related
How can I tell where g++ was able to find an include file? Basically if I
#include <foo.h>
g++ will scan the search path, using any include options to add or alter the path. But, at the end of days, is there a way I can tell the absolute path of foo.h that g++ chose to compile? Especially relevant if there is more than one foo.h in the myriad of search paths.
Short of a way of accomplishing that... is there a way to get g++ to tell me what its final search path is after including defaults and all include options?
g++ -H ...
will also print the full path of include files in a format which shows which header includes which
This will give make dependencies which list absolute paths of include files:
gcc -M showtime.c
If you don't want the system includes (i.e. #include <something.h>) then use:
gcc -MM showtime.c
Sure use
g++ -E -dI ... (whatever the original command arguments were)
If your build process is very complicated...
constexpr static auto iWillBreak =
#include "where/the/heck/is/this/file.h"
This will (almost certainly) cause a compilation error near the top of the file in question. That should show you a compiler error with the path the compiler sees.
Obviously this is worse than the other answers, but sometimes this kind of hack is useful.
If you use -MM or one of the related options (-M, etc), you get just the list of headers that are included without having all the other preprocessor output (which you seem to get with the suggested g++ -E -dI solution).
For MSVC you can use the /showInclude option, which will display the files that are included.
(This was stated in a comment of Michael Burr on this answer but I wanted to make it more visible and therefore added it as a separate answer.)
Usability note: The compiler will emit this information to the standard error output which seems to be suppressed by default when using the windows command prompt. Use 2>&1 to redirect stderr to stdout to see it nonetheless.
I am converting a scatter file to linker file. Now the problem is armlink can accept symbols e.g --predefine=-DSOME_VARIABLE at link time and in the scatter file other header files can be included with the #include "someHeader.h directive. There are files which are included in scatter file on the bases of defined symbols e.g
#ifdef INCLUDE_RANDOM_FILE
randomFile (*)
#endif
in linker script these options are not available. is there a work around for this problem.
There are two fairly simple options.
Use a compiler pre-processor and use the output.
Invert your logic.
Use the C pre-processor in GCC or any compiler.
$(CC) $(DEFINES) -E -P -o output.lds -x c-header input.lds
This option allows the full range of pre-processor defines and conditional inclusion.
The invert option is to have separate master 'lds' files for each case you need and then include the common portion.
flash.lds
start = 0xf000000;
size = 0x100000;
include "common.lds"
ram.lds
start = 0x0;
size = 0x10000;
include "common.lds"
The same can be production and debug variants. This is fairly easy if the permutations are low. Otherwise, I would use the pre-processing.
The bin-utils ld documentation also has a good example with a linkcmds.memory file. You would have to symlink or copy the linkcmds.memory file in your Makefile or build process.
It is often surprisingly easy to get rid of the conditions by using weak symbols and stub file and routines that make conditions unneeded.
I want to preprocess C++ header files keeping all macros verbatim in the output text.
For that, I need a C preprocessor-like program that performs these tasks:
store in memory macros from #define directives;
recursively follow #include directives;
evaluate conditions in #if and #ifdef directives;
suppress the code in inactive portions of #if .. #else .. #endif blocks;
(optionally) remove /* .. */ and // comments;
remove all remaining directives lines.
But the macros must not be replaced in the output. Or alternatively, the preprocessor may take in argument a list of macro names that shall not be replaced.
This may sound weird, but I have a good reason for that. I have a series of Perl scripts able to analyze preprocessed C++ class headers. And I use some macros to tell them for example which methods to export.
I haven't found a preprocessor program able to perform what I need, so I wrote a Perl
script. The latter actually works, but is slow and non standard. I am looking for a better alternative.
Use gcc -E to run the preprocessor manually. This will expand all the macros but that's not a problem.
What you want is special macros for the time when you need the output for your Perl scripts. Try this:
#ifdef PERL_PREPROCESSING
# define EXPORT(...) PERL_EXPORT
#else
# define EXPORT(...) ...normal C code...
#endif
So the idea is that you call gcc -E -DPERL_PREPROCESSING to switch some of the macros to produce output that your perl scripts can locate. The macros will be expanded as usual.
[EDIT] If you don't want to pollute your sources with Perl-specific macros, use this trick: Create a folder which contains the header file with the Perl versions of the macros and include this folder before every other folder with -I. gcc will then ignore the standard header file.
If you are using *nix you can use the grep command to find all the #defines in the directory
grep -R . '#define'
For the preprocessing required, use gcc -E.
How can I tell where g++ was able to find an include file? Basically if I
#include <foo.h>
g++ will scan the search path, using any include options to add or alter the path. But, at the end of days, is there a way I can tell the absolute path of foo.h that g++ chose to compile? Especially relevant if there is more than one foo.h in the myriad of search paths.
Short of a way of accomplishing that... is there a way to get g++ to tell me what its final search path is after including defaults and all include options?
g++ -H ...
will also print the full path of include files in a format which shows which header includes which
This will give make dependencies which list absolute paths of include files:
gcc -M showtime.c
If you don't want the system includes (i.e. #include <something.h>) then use:
gcc -MM showtime.c
Sure use
g++ -E -dI ... (whatever the original command arguments were)
If your build process is very complicated...
constexpr static auto iWillBreak =
#include "where/the/heck/is/this/file.h"
This will (almost certainly) cause a compilation error near the top of the file in question. That should show you a compiler error with the path the compiler sees.
Obviously this is worse than the other answers, but sometimes this kind of hack is useful.
If you use -MM or one of the related options (-M, etc), you get just the list of headers that are included without having all the other preprocessor output (which you seem to get with the suggested g++ -E -dI solution).
For MSVC you can use the /showInclude option, which will display the files that are included.
(This was stated in a comment of Michael Burr on this answer but I wanted to make it more visible and therefore added it as a separate answer.)
Usability note: The compiler will emit this information to the standard error output which seems to be suppressed by default when using the windows command prompt. Use 2>&1 to redirect stderr to stdout to see it nonetheless.
I have a perl script I'd like to filter my cpp/h files through before gcc processes them normally -- basically as an extra preprocessing step. Is there an easy way to do this? I realize I can feed the cpp files to the script and have gcc read the output from stdin, but this doesn't help with the header files.
The classic way to handle such a process is to treat the source code (input to the Perl filter) as a new language, with a new file suffix. You then tell make that the way to compile a C++ source file from this new file type is with the Perl script.
For example:
New suffix: .ccp
New rule (assuming .cc suffix):
.ccp.cc:
${FILTERSCRIPT} $<
Add the new suffix to the suffix list - with priority over the normal C++ rules.
The last point is the trickiest. If you just add the .ccp suffix to the list, then make won't really pay attention to changes in the .ccp file when the .cc file exists. You either have to remove the intermediate .cc file or ensure that .ccp appears before .cc in the suffixes list. (Note: if you write a '.ccp.o' rule without a '.ccp.cc' rule and don't ensure that that the '.cc' intermediate is cleaned up, then a rebuild after a compilation failure may mean that make only compiles the '.cc' file, which can be frustrating and confusing.)
If changing the suffix is not an option, then write a compilation script that does the filtering and invokes the C++ compiler directly.
The C and C++ preprocessor does not have any support for this kind of thing. The only way to handle this is to have your makefile (or whatever) process all the files through the perl script before calling the compiler. This is obviously very difficult, and is one very good reason for not designing architectures that need such a step. What are you doing that makes you think you need such a facility? There is probably a better solution that you are not aware of.
How about a wrapper around gcc that runs your Perl script and then calls gcc? Call it something like plgcc and set CC=plgcc in your makefile. Your script will have to be smart enough to process the include directives -- unless your script calls just the pre-processor to bring in the includes, does its thing, and then calls gcc.
GCC allows you to use your own preprocessor. You could set your script as the preprocessor then run the output through cpp (the normal gcc pre-processor). Look at the gcc manual for -B and -no-integrated-cpp command line options.
Warning - I have never tried it myself so don't know how messy it might be (bear in mind though that for many years lots of languages, including C++, were implemented as preprocessors to a c compiler so support shouldn't be too bad).
I've handled cases like this in the past by doing something like the following. This approach assumes that the unprocessed source code can be distinguished through a naming scheme of some sort, in this case suffixing the basename with _pp.
# These are your source files to be preprocessed
SRC_RAW = mysrc_pp.cpp
# These are the source files after preprocessing
SRC_PP = $(patsubst %_pp.cpp, %.cpp, $(SRC_RAW))
ALL_SRC = $(SRC) main.cpp other.cpp
OBJ = $(patsubst %.cpp, %.o, $(ALL_SRC))
$(SRC): %.cpp: %_pp.cpp
$(PERL) $< > $#
$(OBJ): %.o: %.cpp
$(CXX) ...
This does not, however, handle the case where you have header files which need preprocessing. In that case you would need similar rules for creating them.