Closed schra closed 3 years ago
Firstly thanks for the PR, but I am confused about what you are implementing.
Can you give me an example of the kind of expansion which does occur, and which does not, for the current semantics, with passthru on, and with your proposed PR?
Can you give me an example of the kind of expansion which does occur, and which does not, for the current semantics, with passthru on, and with your proposed PR?
Sure:
$ cat foo.h
#define FOO 1
void my_func1();
void my_func2();
void my_func3();
$ cat bar.c
#include "foo.h"
#ifdef FOO
TRUE
#else
FALSE
#endif
$ pcpp bar.c
#line 3 "foo.h"
void my_func1();
void my_func2();
void my_func3();
#line 4 "bar.c"
TRUE
$ pcpp --passthru-defines --passthru-unfound-includes --passthru-unknown-exprs --passthru-comments --passthru-magic-macros bar.c
#line 1 "foo.h"
#define FOO 1
void my_func1();
void my_func2();
void my_func3();
#line 4 "bar.c"
TRUE
$ pcpp --no-expand-includes bar.c
#include "foo.h"
#line 4 "bar.c"
TRUE
Note that with --no-expand-includes
you now have the line #include "foo.h"
and not have the function declarations.
Also note that using any of the available passthru options doesn't avoid expanding includes.
As you can see, pcpp "expands" includes by default. Via --no-expand-includes
you avoid "expanding" #include
commands (#include
commands will persist in the output). However the interesting point of --no-expand-includes
is that while it doesn't expand the #include
, it still evaluates it. Thus e.g. definitions from included files are still visible.
My concrete use case for --no-expand-includes
is the following: I'm currently reading the source code of https://github.com/chriskohlhoff/asio and the library uses A LOT of macros. So my idea was to just expand all macros first and then read its source. However, when I use pcpp
then also the #include
s will be expanded which will make the expanded asio files unreadable (and very big). So I implemented this option to preserve the #include
s.
I think I have implemented what you have asked for, but not in the way you did it in your PR, nor indeed with the same semantics for the command line arg. Give it a try, let me know if this ticks your box.
Going to assume this is fixed.
Not sure if this is something that you would like to integrate into upstream. But I thought that I might as well just share my diff.
This option solves the use case where we want to expand all macros but includes in a file. Since some macros however might be defined inside the includes, we still want to evaluate them.