Skip to content

Conversation

@KornevNikita
Copy link
Contributor

@KornevNikita KornevNikita commented Oct 30, 2025

There is a customer request to make clang version output more
informative. This patch adds a string like this to the output:
"Intel SYCL compiler X build based on:" - here goes regular clang output.
Where X is "development" by default.
"Nightly YYYY-MM-DD" for regular nightly builds.
"X.Y.Z Nightly YYYY-MM-DD" for nightly release builds.
"X.Y.Z release" for official releases.

This patch adds "Nightly build" string to clang version output.
Previously it was like:
clang version 22.0.0git (https://github.com/intel/llvm.git
2de7d37)
Now it looks like:
clang version 22.0.0git (https://github.com/intel/llvm.git 2de7d37 Nightly build)

I'm preserving the repo path, but extending the revision. Anyways, we need to define both CLANG_VC_REPOSITORY and CLANG_VC_REVISION CMake variables to redefine the output, see: llvm/llvm/cmake/modules/GenerateVersionFromVCS.cmake

Moreover, we need to define LLVM_VC_REPOSITORY & LLVM_VC_REVISION,
because if it's not the same as CLANG_VC_* variables, there will be two
sections of brackets after clang version, like:
clang version 22.0.0git (https://github.com/intel/llvm.git
2de7d37) (https://github.com/intel/llvm.git 2de7d37 Nightly build)

This is kind of hacky, but it allows as not to change the source code.
@KornevNikita KornevNikita requested a review from a team as a code owner October 30, 2025 17:41
build_configure_extra_args: '--hip --cuda'
build_configure_extra_args: |
--hip --cuda \
-DLLVM_VC_REPOSITORY="${{ github.repositoryUrl }}" -DLLVM_VC_REVISION="${{ github.sha }} Nightly build" \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since we're only doing this for the nightly, is there some benefit we get to knowing if someone is using the nightly or not?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll also add the same thing for nightly release builds like x.y.z pre-release build and x.y.z release build for official releases, so this is needed to distinguish them.

@bader
Copy link
Contributor

bader commented Oct 30, 2025

This patch adds "Nightly build" string to clang version output.

Why? How is the "nightly build" different from regular non-nightly build?

@KornevNikita
Copy link
Contributor Author

This patch adds "Nightly build" string to clang version output.

Why? How is the "nightly build" different from regular non-nightly build?

What you mean by regular non-nightly build? There is a huge set of options on how to build the toolchain. Nightly builds are built in some specific way, tested properly enough and published. So there is a customer request to make the version info a bit more informative.

KornevNikita added a commit that referenced this pull request Oct 31, 2025
For more details see: #20520

This PR adds branch:hash to nightly builds on release branches.
It also allows to specify a custom version manually in case of official
release builds, e.g. "6.3.0 release build".
@bader
Copy link
Contributor

bader commented Oct 31, 2025

What you mean by regular non-nightly build?

I mean builds done by other workflows (e.g. pre-commit, post-commit, etc.).

So there is a customer request to make the version info a bit more informative.

What is missing in the current version info? How does you change make it more informative?

KornevNikita added a commit that referenced this pull request Nov 3, 2025
Previous attempt: #20520
That one is kind of hacky, therefore proceeding with a more proper
solution.

There is a customer request to make clang version output more
informative. This patch adds a string like this to the output:
"Intel SYCL compiler X build based on:" - here goes regular clang output.
Where X is "development" by default.
"Nightly" for regular nightly builds.
"X.Y.Z Nightly" for nightly release builds.
"X.Y.Z release" for official releases.
@KornevNikita
Copy link
Contributor Author

Closing in favor of #20536.
@bader could you please check the new PR.

@bader
Copy link
Contributor

bader commented Nov 3, 2025

Closing in favor of #20536.
@bader could you please check the new PR.

@KornevNikita, why did you open another PR? Please, use one PR for all the discussions/review process.
I suggest you re-open this one and reply to my questions above. I don't any of my questions to be answered in #20536.

There is a customer request to make clang version output more
informative. This patch adds a string like this to the output:
"Intel SYCL compiler X build based on:" - here goes regular clang output.
Where X is "development" by default.
"Nightly" for regular nightly builds.
"X.Y.Z Nightly" for nightly release builds.
"X.Y.Z release" for official releases.
@KornevNikita KornevNikita requested review from a team as code owners November 4, 2025 10:12
@KornevNikita KornevNikita changed the title [SYCL][CI] Improve clang++ version output [Clang][CI] Extend clang version output Nov 4, 2025
@KornevNikita
Copy link
Contributor Author

@bader I've updated the PR, could you please check the description, as the approach was changed a bit.

What is missing in the current version info? How does you change make it more informative?

The build info is missing. Some people are using our nightly builds, so they need this info to distinguish builds, I guess. If you're still against this change, then we can drop it, as I have nothing to say more here. Maybe @AlexeySachkov has some.

Anyways, we still need this change to mark our official releases, as of now clang says nothing about it. Do you have any concerns regarding this point?

@elizabethandrews
Copy link
Contributor

Anyways, we still need this change to mark our official releases, as of now clang says nothing about it. Do you have any concerns regarding this point?

@mdtoguchi can you confirm this? I thought we emitted release information ?

@bader
Copy link
Contributor

bader commented Nov 4, 2025

The build info is missing. Some people are using our nightly builds, so they need this info to distinguish builds, I guess. If you're still against this change, then we can drop it, as I have nothing to say more here.

@KornevNikita, I'm confused. I don't understand what exactly the problem you are trying to solve by adding "Nightly" string to the version reported by the driver.
Why commit SHA reported by the driver today is not enough? Do you have a reference to the requests from "some people"?

Anyways, we still need this change to mark our official releases, as of now clang says nothing about it. Do you have any concerns regarding this point?

@mdtoguchi can you confirm this? I thought we emitted release information ?

I agree. I would expect our compiler to emit the version similar to the upstream compiler.

@mdtoguchi
Copy link
Contributor

mdtoguchi commented Nov 4, 2025

Anyways, we still need this change to mark our official releases, as of now clang says nothing about it. Do you have any concerns regarding this point?

@mdtoguchi can you confirm this? I thought we emitted release information ?

There is additional release information emitted with the Intel compiler, but as I understand it the intel/llvm bits just emit the clang version.

@AlexeySachkov
Copy link
Contributor

The build info is missing. Some people are using our nightly builds, so they need this info to distinguish builds, I guess. If you're still against this change, then we can drop it, as I have nothing to say more here.

@KornevNikita, I'm confused. I don't understand what exactly the problem you are trying to solve by adding "Nightly" string to the version reported by the driver. Why commit SHA reported by the driver today is not enough? Do you have a reference to the requests from "some people"?

CMPLRLLVM-68631 is the internal tracker number. Hash does not exactly describe where a build is coming from: for example a local build and a build downloaded from nightly can have the same hash, but they could be built with different flags or options (like support for device image compression, or SYCL JIT). Another benefit is that we can instantly compare two nightly builds to understand which one is newer/older, without having to look up a commit hash in the repo. However, I do not see this part being implemented despite it being mentioned in the description - without it just "Nightly" string alone does not bring much benefit

@KornevNikita
Copy link
Contributor Author

KornevNikita commented Nov 5, 2025

Anyways, we still need this change to mark our official releases, as of now clang says nothing about it. Do you have any concerns regarding this point?

@mdtoguchi can you confirm this? I thought we emitted release information ?

There is additional release information emitted with the Intel compiler, but as I understand it the intel/llvm bits just emit the clang version.

Yes, there is such mechanism in the internal compiler version, but intel/llvm clang currently reports the same info as llvm-project clang.

without it just "Nightly" string alone does not bring much benefit

Added date.

@bader
Copy link
Contributor

bader commented Nov 5, 2025

I want @AlexeySachkov to decide the readiness of this change as he is in context of the customer request mentioned in the description. @KornevNikita, please, get approval from @AlexeySachkov before merging this PR.

Copy link
Contributor

@elizabethandrews elizabethandrews left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add tests with mock values?

@KornevNikita
Copy link
Contributor Author

@elizabethandrews

Can you add tests with mock values?

Hmm, it's kind of tricky since we need to re-build clang to get the updated output, not sure how to implement it. Do you have any thoughts? At least we could add a test to Nightly to check if the output is right.

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.

7 participants