Make P4-14 optional.
Fixes #4776. Add a CMake option to enable P4-14. Otherwise, add a bunch of code pragmas to selectively disable P4-14 constructs. We can clean these up over time.
The move of v1model.h to the BMv2 back end is intentional. With that it becomes clear which front/mid end segments are "dirty", i.e., they depend on back-end-specific code.
We'll need to ensure some CI builds are built with P4_14 and some without. Not sure we need every possible combination of OS + build tool + P4_14 on/off + unity on/off, but at least some orthogonal coverage.
Yes, my plan is to have one CI run that still builds with P4-14. I opened this PR a bit prematurely, there are still some changes necessary. P4-14 constructs are spread all across the front and mid end.
@smolkaj This PR makes the P4-14 parts optional. With respect to Bazel, I can remove the P4-14 parts from the build system (e.g. v1lexer) or enable building with P4-14 (this is the previous behavior). What do you prefer?
I can also try to add a toggle like we do in CMake, but I am not sure whether Bazel supports that well.
@smolkaj This PR makes the P4-14 parts optional. With respect to Bazel, I can remove the P4-14 parts from the build system (e.g. v1lexer) or enable building with P4-14 (this is the previous behavior). What do you prefer?
I can also try to add a toggle like we do in CMake, but I am not sure whether Bazel supports that well.
I don't think we need P4-14 support. I just want to make sure i understand -- P4-16 programs using v1model will continued to work?
See some comments. I'm not a huge fan of bunch of ifdefs spread across the whole frontend... Maybe this could be composed in some other way?
I am converting some of this into issues, e.g., https://github.com/p4lang/p4c/issues/5402. I also want to reduce the #ifdefs as much as possible but some refactorings are a little bit more involved (for example, splitting out the v1parser).
I don't think we need P4-14 support. I just want to make sure i understand -- P4-16 programs using v1model will continued to work?
Yes, this will not affect P4-16 programs, but you might lose the ability to compile P4-14 programs. I do not think you work with those.
https://github.com/p4lang/p4c/pull/5399/commits/6ddcd13d2f442f9493ece1ac157edf5cc63e9d0c is a possible implementation in Bazel