Fix P4C extension boilerplate CI build & test issue

[qobilidop]

No description provided.

[asl]

I believe this is fixed by https://github.com/p4lang/p4mlir-incubator/pull/7/files#diff-1e7de1ae2d059d21e1dd75d5812d5a34b0222cef273b7c3a2af62eb747f9d20aR12 or some additional changes in third-party/llvm/CMakeLists.txt in the same PR.

[qobilidop]

Thanks! Let me take a look.

[qobilidop]

I'm still not able to resolve this. If you are also okay with it, I suggest we leave this as a TODO. So we can re-enable CI test on other PRs sooner.

[qobilidop]

Somehow the build-and-test check is not automatically triggered after pushing more commits. I've manually triggered it in https://github.com/p4lang/p4mlir-incubator/actions/runs/12983849029/job/36236520316.

[qobilidop]

Somehow the build-and-test check is not automatically triggered after pushing more commits. I've manually triggered it in https://github.com/p4lang/p4mlir-incubator/actions/runs/12983849029/job/36236520316.

Well, that doesn't seem to be testing the latest commit. Let me try using #33.

[qobilidop]

https://github.com/p4lang/p4mlir-incubator/actions/runs/12994911907/job/36240417411#step:9:12345

+ ninja check-p4mlir
[0/1] Running the P4MLIR regression tests
-- Testing: 2 tests, 2 workers --
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 

Testing Time: 0.04s

Total Discovered Tests: 2
  Passed: 2 (100.00%)

Now the CI test can pass!

I'll take another look at the CMake hack issue after work today.

[asl]

Now the CI test can pass!

I'll take another look at the CMake hack issue after work today.

Still, it seems you returned to the old way of building LLVM separately rather than doing it as a sub-project. I found the former approach quite error-prone during development:

• It could peek "wrong" LLVM build that might happen to be on developer's machine (and I do have lots of different LLVM trees locally, for now we stick to LLVM 19 release)
• We need to build LLVM in non-default mode (need to have both RTTI and EH enabled as P4C relies on them and this is an ABI-breaking change, you cannot mix and match things).

Note that after https://github.com/p4lang/p4mlir-incubator/pull/7/files everything is supposed to work if the code is just dropped into extensions subdir of P4C, it would just build LLVM as a necessary dependency with all required options and propagate stuff further. We'd also just stash whole P4C with all dependencies into the cache there.

[qobilidop]

@asl Thanks for your comments!

The main reason I switched back to the old CMake config was to start from a known working state to better isolate CI issues. Now that things are working in CI, I'm taking another look at CMake changes in #3 and #7.

I have to admit that my knowledge on CMake is quite limited. So I still don't fully understand some of your comments. Let me explain my current understanding below, and maybe you can help me clarify my misunderstandings.

Overall, I was following the out-of-tree component build approach from the MLIR standalone example. I noticed that this approach is used in some popular MLIR-based projects, like CIRCT. So I was assuming it is a solid approach and just went with it.

Still, it seems you returned to the old way of building LLVM separately rather than doing it as a sub-project. I found the former approach quite error-prone during development:

• It could peek "wrong" LLVM build that might happen to be on developer's machine (and I do have lots of different LLVM trees locally, for now we stick to LLVM 19 release)

I thought we could specify local LLVM locations when building an out-of-tree MLIR project, by passing in some CMake options, like the following:

p4mlir-incubator/build_tools/build_p4mlir.sh

Lines 21 to 24 in af6e91b

	cmake -G Ninja "$P4MLIR_REPO_DIR" \
	-DCMAKE_INSTALL_PREFIX="$LLVM_INSTALL_DIR" \
	-DMLIR_DIR="$LLVM_INSTALL_DIR"/lib/cmake/mlir \
	-DLLVM_EXTERNAL_LIT="$LLVM_BUILD_DIR"/bin/llvm-lit

Or maybe that's not enough?

• We need to build LLVM in non-default mode (need to have both RTTI and EH enabled as P4C relies on them and this is an ABI-breaking change, you cannot mix and match things).

Is that achievable with the out-of-tree approach as well? We currently have the following script for building LLVM/MLIR:

p4mlir-incubator/build_tools/build_mlir.sh

Lines 20 to 29 in af6e91b

	cmake -G Ninja "$LLVM_REPO_DIR"/llvm \
	-DCMAKE_INSTALL_PREFIX="$LLVM_INSTALL_DIR" \
	-DLLVM_ENABLE_PROJECTS=mlir \
	-DLLVM_BUILD_EXAMPLES=OFF \
	-DLLVM_TARGETS_TO_BUILD="Native" \
	-DCMAKE_BUILD_TYPE=Release \
	-DLLVM_ENABLE_ASSERTIONS=ON \
	-DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DLLVM_ENABLE_LLD=ON \
	-DLLVM_CCACHE_BUILD=ON \
	-DLLVM_INSTALL_UTILS=ON

I imagine we could tweak CMake options here to enable RTTI and EH, right?

Note that after https://github.com/p4lang/p4mlir-incubator/pull/7/files everything is supposed to work if the code is just dropped into extensions subdir of P4C, it would just build LLVM as a necessary dependency with all required options and propagate stuff further. We'd also just stash whole P4C with all dependencies into the cache there.

Then it seems to make more sense to rebase this PR to #7. I'll try it.

[qobilidop]

@asl How about making out-of-tree build optional for now? This way your local development workflow won't be disrupted. And our current CI build scripts also work.

[qobilidop]

This is superseded by #46.