pcpp cannot handle our code: What's the best path forward?

[mathomp4]

In Ford 7, pcpp is now the default preprocessor. We've found that with MAPL this does not work, see https://github.com/GEOS-ESM/MAPL/actions/runs/6933072181/job/18858418856 for an example.

We can duplicate this locally on a mac if pcpp is installed. Now, MAPL is pretty complex Fortran with lots of includes to gFTL which is a quite complex set of macros, perhaps pcpp does not like it?

We can "fix" this issue by adding:

preprocessor: cpp -traditional-cpp -E

in our control file and all is well.

So, what is the right path forward? This seems a bug in pcpp but I'm not sure internally how pcpp is called by Ford. @ZedThree Can you tell me how I could work on getting a reproducer to the pcpp folks to show them they have an issue?

cc: @JulesKouatchou

[ZedThree]

Yep, that's the correct fix. I switched to pcpp as it's a Python package so I could just add it to the dependencies of Ford and not have to worry about gfortran/cpp being installed on the target machine -- useful for running in CI!

pcpp is just called like pcpp -D<defines> -I<includes> <sourcefile>. If it fails, ford should print the command that failed. If you're not getting that, then you can double check the command line here:

ford/ford/reader.py

Line 169 in 141b80a

command = " ".join(preprocessor)

Stick a print(f{"command=}") there and you should see exactly how pcpp is called.

[mathomp4]

Okay. I think I see the issue:

❯ rg 'procedure :: capacity'
file_from_cpp12
638:         procedure :: capacity => ti_capacity
2086:         procedure :: capacity => tt_capacity

file_from_pcpp
351:         procedure :: capacity => ti_ capacity
1456:         procedure :: capacity => tt_ capacity

for some reason, pcpp is putting in an extra space in a LOT of calls. So it's getting ti_ capacity instead of ti_capacity.

[mathomp4]

Okay. Issue filed at pcpp, ned14/pcpp#84, but I'm guessing the fact we seem to rely on -traditional-cpp means we might be out of luck. Luckily, not too hard to get GNU cpp on most systems.

[ZedThree]

Ah, that's a pain! This is probably worth turning into a FAQ, I imagine it will come up again

[mathomp4]

Yeah. And it looks like it's a wontfix for the pcpp folks (as expected). As I said in that issue, the "right" thing is to wait for the Fortran 202Y Standard Preprocessor and we can make a pfpp at that point.

[mathomp4]

Also, as an aside, I think the readthedocs here still points to the Ford 6 info. That's why I was a bit confused about the pcpp stuff.