Skip to content

[libclc] Convert tabs to spaces in CMake #85634

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

Merged
merged 1 commit into from
Mar 18, 2024

Conversation

frasercrmck
Copy link
Contributor

Having a mix of tabs and spaces makes the diff of any changes to the build system noisier than necessary. This commit unifies them to two spaces.

This includes some minor cosmetic changes such as with joining things on one line where appropriate.

There are other files in libclc which have tabs but those haven't been touched at this time. Those could come at another time if desired, though they might be more contentious as the project isn't clang-formatted at all and so that might invite larger discussions around formatting.

Having a mix of tabs and spaces makes the diff of any changes to the
build system noisier than necessary. This commit unifies them to two
spaces.

This includes some minor cosmetic changes such as with joining things on
one line where appropriate.

There are other files in libclc which have tabs but those haven't been
touched at this time. Those could come at another time if desired,
though they might be more contentious as the project isn't
clang-formatted at all and so that might invite larger discussions
around formatting.
@frasercrmck
Copy link
Contributor Author

@tstellar are you the code owner for libclc?

@frasercrmck
Copy link
Contributor Author

FWIW I don't think the build bots are actually building libclc.

Locally, at least, it's not sufficient to specify LLVM_ENABLE_PROJECTS=libclc - you also need LLVM_EXTERNAL_PROJECTS=libclc. Even then, it doesn't build for me in-tree, because it assumes CMAKE_SOURCE_DIR is its own top-level directory, which it isn't as it's llvm/.

I had a patch locally to switch CMAKE_SOURCE_DIR to PROJECT_SOURCE_DIR which I think is sufficient to cover both build styles. Should I contribute this upstream?

Another problem is that all libclc targets are enabled by default, but the spirv-mesa3d and spirv64-mesa3d targets both need llvm-spirv which I doubt our buildbots have available. Should those be disabled by default, or should the buildbots disable them?

@tstellar
Copy link
Collaborator

FWIW I don't think the build bots are actually building libclc.

Locally, at least, it's not sufficient to specify LLVM_ENABLE_PROJECTS=libclc - you also need LLVM_EXTERNAL_PROJECTS=libclc. Even then, it doesn't build for me in-tree, because it assumes CMAKE_SOURCE_DIR is its own top-level directory, which it isn't as it's llvm/.

I had a patch locally to switch CMAKE_SOURCE_DIR to PROJECT_SOURCE_DIR which I think is sufficient to cover both build styles. Should I contribute this upstream?

Another problem is that all libclc targets are enabled by default, but the spirv-mesa3d and spirv64-mesa3d targets both need llvm-spirv which I doubt our buildbots have available. Should those be disabled by default, or should the buildbots disable them?

I'm not aware of any bots building libclc. It would be nice if you could build libclc more easily, it does not fit in with the rest of the projects right now. Any improvements you want to make in this area would be welcome.

@frasercrmck frasercrmck merged commit 9253950 into llvm:main Mar 18, 2024
@frasercrmck frasercrmck deleted the reformat-libclc-buildsystem branch March 18, 2024 14:37
@frasercrmck
Copy link
Contributor Author

FWIW I don't think the build bots are actually building libclc.
Locally, at least, it's not sufficient to specify LLVM_ENABLE_PROJECTS=libclc - you also need LLVM_EXTERNAL_PROJECTS=libclc. Even then, it doesn't build for me in-tree, because it assumes CMAKE_SOURCE_DIR is its own top-level directory, which it isn't as it's llvm/.
I had a patch locally to switch CMAKE_SOURCE_DIR to PROJECT_SOURCE_DIR which I think is sufficient to cover both build styles. Should I contribute this upstream?
Another problem is that all libclc targets are enabled by default, but the spirv-mesa3d and spirv64-mesa3d targets both need llvm-spirv which I doubt our buildbots have available. Should those be disabled by default, or should the buildbots disable them?

I'm not aware of any bots building libclc. It would be nice if you could build libclc more easily, it does not fit in with the rest of the projects right now. Any improvements you want to make in this area would be welcome.

Ah, yeah that's possible. I mentioned it because https://github.com/llvm/llvm-project/blob/main/.github/workflows/libclc-tests.yml and https://buildkite.com/llvm-project/github-pull-requests/builds/48183#018e5157-23d0-4c70-b8bc-54bbdceabb6c look like they're ostensibly trying to build it, but aren't.

I'll see what I can do to improve the situation. We're mostly working with libclc downstream in DPC++ and it's been changed quite significantly, so it's a bit delicate to get the balance right.

frasercrmck added a commit to frasercrmck/llvm that referenced this pull request Mar 18, 2024
This mirrors a change made to upstream LLVM in
llvm/llvm-project#85634, but since we've made
downstream changes we have to do the work in two places.

Some of this will cause merge conflicts when pulling down upstream LLVM
but I don't know how we can avoid that.

Some of the other files changed in the upstream PR have been left alone
here since we'll soon pull those in anyway.
ldrumm pushed a commit to intel/llvm that referenced this pull request Mar 19, 2024
This mirrors a change made to upstream LLVM in
llvm/llvm-project#85634, but since we've made
downstream changes we have to do the work in two places.

Some of this will cause merge conflicts when pulling down upstream LLVM
but I don't know how we can avoid that.

Some of the other files changed in the upstream PR have been left alone
here since we'll soon pull those in anyway.
chencha3 pushed a commit to chencha3/llvm-project that referenced this pull request Mar 23, 2024
Having a mix of tabs and spaces makes the diff of any changes to the
build system noisier than necessary. This commit unifies them to two
spaces.

This includes some minor cosmetic changes such as with joining things on
one line where appropriate.

There are other files in libclc which have tabs but those haven't been
touched at this time. Those could come at another time if desired,
though they might be more contentious as the project isn't
clang-formatted at all and so that might invite larger discussions
around formatting.
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.

2 participants