Possible to emulate -traditional-cpp behavior?

[mathomp4]

When Ford recently moved to use pcpp as its default preprocessor, we found our docs failed to build during the preprocessing step (see https://github.com/Fortran-FOSS-Programmers/ford/issues/600).

The issue seems to be that we sort of rely on -traditional-cpp behavior of GNU cpp; I'm guessing because we are preprocessing Fortran and not C.

For example, given this Fortran code:

#  define __QUOTE(x) x
#  define __PROC(x) __QUOTE(a)__QUOTE(x)

__PROC(b)

with GNU cpp and -traditional-cpp:

❯ cpp-12 -traditional-cpp test.F90
# 0 "test.F90"
# 0 "<built-in>"
# 0 "<command-line>"
# 1 "test.F90"

ab

and ab is what we'd expect and we get the same behavior with NAG's fpp preprocessor.

But with pcpp:

❯ pcpp test.F90
#line 4 "test.F90"
a b

there is an extra space and so things go wonky. Similar for cpp without the flag:

❯ cpp-12 test.F90
# 0 "test.F90"
# 0 "<built-in>"
# 0 "<command-line>"
# 1 "test.F90"

a b

I guess my question is: is there a way to emulate the -traditional-cpp behavior with pcpp? Or is that sort of...antithetical to pcpp's purpose?

Note: I can't remember why, but there is a portability reason this layer doesn't use ## concatenation or other things, but I'd have to consult the dev. What we've found is this is our most

[ned14]

pcpp matches the ISO C preprocessor here (https://godbolt.org/z/qdr7Ka8Yj), so I'm not especially warm to special opt out flags, as then people would want more so they can have pcpp match MSVC's broken preprocessor and other such carve outs.

You could fork pcpp?

[mathomp4]

pcpp matches the ISO C preprocessor here (https://godbolt.org/z/qdr7Ka8Yj), so I'm not especially warm to special opt out flags, as then people would want more so they can have pcpp match MSVC's broken preprocessor and other such carve outs.

You could fork pcpp?

Ehhh. Not that important as Ford (via @ZedThree) provides us a workaround. I just didn't know if one of the many options pcpp has emulated it. If it doesn't, it doesn't.

My guess is the "right" solution is to wait a few years until Fortran 202Y is out which I believe will introduce a preprocessor into the Fortran Standard. Then at that point, someone ambitious can make pfpp.