Add --cc flag to specify the C preprocessor binary

[smolkaj]

Problem

ParserOptions::preprocess() hardcodes the preprocessor command to cc -E (clang) or cpp (GCC):

https://github.com/p4lang/p4c/blob/main/frontends/common/parser_options.cpp#L419-L422

#ifdef __clang__
        std::string cmd("cc -E -x c -Wno-comment");
#else
        std::string cmd("cpp");
#endif

There is no CLI flag to override this. Callers that need to provide a specific C preprocessor — most commonly because they're running in a hermetic sandbox without a system cc on PATH — have to resort to workarounds.

p4c's own p4_library.bzl works around this with a bash shell function:

function cc () {{ "{cc}" "$@"; }}
export -f cc

This works for ctx.actions.run_shell (Bazel actions) but breaks in contexts where the caller can't inject shell functions — e.g., Java/Kotlin ProcessBuilder, non-bash shells, or any environment where export -f isn't available.

Proposal

Add a --cc <path> flag (or --preprocessor <path>) that lets the caller specify the C preprocessor binary. When set, preprocess() would use the provided path instead of the hardcoded cc/cpp.

This would let Bazel rules pass the CC toolchain's compiler_executable directly, eliminating the shell function workaround in both p4_library.bzl and downstream rules.

Motivation

• Hermetic build environments (Bazel remote execution, google3/blaze) don't have cc on PATH. Every consumer of p4c in these environments needs to work around this independently.
• Non-shell callers (JVM ProcessBuilder, Python subprocess, etc.) can't use export -f and have to manipulate PATH to inject a shim script — fragile and error-prone.
• p4c already knows about this problem — the shell function pattern in p4_library.bzl is the proof. A first-class flag would be cleaner for p4c's own Bazel rules too.

[ChrisDodd]

Note that the code in parser_options.cpp is not expected to be run normally -- it is a debugging hack to make it easier to run the compiler under a debugger (such as gdb) and not need to manually run the preprocessor.

For a normal installation, the preprocessor should be run by the p4c driver -- the code in driver/p4c_src/p4c.TARGET.cfg (for each TARGET) will run the preprocessor.

[fruffy]

Note that the code in parser_options.cpp is not expected to be run normally -- it is a debugging hack to make it easier to run the compiler under a debugger (such as gdb) and not need to manually run the preprocessor.

For a normal installation, the preprocessor should be run by the p4c driver -- the code in driver/p4c_src/p4c.TARGET.cfg (for each TARGET) will run the preprocessor.

From the usage I have seen the preprocessor that's part of the parser has been long assumed to be the default. The driver is not used by many projects. Part of the reason why is that the parser preprocessor runs unless you toggle doNotPreprocess.

If it is not meant to be used we should disable it, move it out of the parser, or make it off by default.