Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[cmake] fix llvm out-of-tree build for one-step build strategy #193

Merged
merged 1 commit into from
Oct 16, 2023

Conversation

Avimitin
Copy link
Contributor

@Avimitin Avimitin commented Sep 1, 2023

The current one-step build strategy requires LLVM sources to be placed in the buddy-mlir project and named 'llvm'. This makes packaging a difficult task, as users can't build buddy-mlir with other working llvm source code that has a different version to the one provided by buddy-mlir.

This commit sets 'LLVM_PROJECT_SOURCE_DIR' to be the up dir of 'LLVM_MAIN_SRC_DIR'. 'LLVM_MAIN_SRC_DIR' is set when building within the llvm source directory, so it is safe to use it as the relative path to llvm project.

The current one-step build strategy requires LLVM sources to be placed
in the buddy-mlir project and named 'llvm'. This makes packaging a
difficult task, as users can't build buddy-mlir with other working llvm source
code that has a different version to the one provided by buddy-mlir.

This commit sets 'LLVM_PROJECT_SOURCE_DIR' to be the up dir of
'LLVM_MAIN_SRC_DIR'. 'LLVM_MAIN_SRC_DIR' is set when building within the llvm
source directory, so it is safe to use it as the relative path to llvm project.

Signed-off-by: Avimitin <[email protected]>
@Avimitin Avimitin requested a review from zhanghb97 September 1, 2023 10:17
@linuxlonelyeagle
Copy link
Member

To be honest, I think this would lead to the problem that using a different version of LLVM wouldn't compile the code, and in this case, every update of LLVM would require us to modify the buddy-mlir code to adapt it to the new version of LLVM.

@Avimitin
Copy link
Contributor Author

Avimitin commented Sep 3, 2023

No, it won't. The buddy-mlir project vendored llvm is already an announcement to other users that this is the only supported version of the llvm project. So if someone wants to use a different llvm source, it's their responsibility to keep llvm and buddy-mlir in sync. For me, it will be much easiler to package buddy-mlir in some traditional package managers. For normal users who just want to use budd-mlir to test and build something, this PR doesn't affect the normal git submodule workflow. Instead, the current build system doesn't need to find out where the llvm source code is: we already run those build commands inside the llvm worktree.

@Avimitin
Copy link
Contributor Author

Avimitin commented Sep 5, 2023

@zhanghb97 how do you think about this PR? It doesn't affect our current workflow but can also benefit other packagers. I think merging this change won't have bad effect.

@zhanghb97 zhanghb97 merged commit 94b698b into buddy-compiler:main Oct 16, 2023
1 check passed
@zhanghb97
Copy link
Member

@Avimitin Thanks! Sorry for the late reply!

ShiHaoGao pushed a commit to ShiHaoGao/buddy-mlir that referenced this pull request Oct 18, 2024
…-compiler#193)

The current one-step build strategy requires LLVM sources to be placed
in the buddy-mlir project and named 'llvm'. This makes packaging a
difficult task, as users can't build buddy-mlir with other working llvm source
code that has a different version to the one provided by buddy-mlir.

This commit sets 'LLVM_PROJECT_SOURCE_DIR' to be the up dir of
'LLVM_MAIN_SRC_DIR'. 'LLVM_MAIN_SRC_DIR' is set when building within the llvm
source directory, so it is safe to use it as the relative path to llvm project.

Signed-off-by: Avimitin <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants