[SYCL] Add in-source versioning for DPCPP compiler

[elizabethandrews]

DPC++ Version Information is now stored in compiler source. clang --version will continue to display build information when local CI is used (i.e. SYCL_BUILD_INFO is defined), but will display in-source version otherwise.

cmake/Modules/DPCPPVersion.cmake should be updated to hold version information for each release.

Example Output:

DPC++ compiler 6.3.0 build based on:
clang version 23.0.0git (https://github.com/intel/llvm.git 5947c2aff087f88c90dcd56857405270ff0d4010)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: */releasebuild/bin
Build config: +assertion

Fixes: #21510

[elizabethandrews]

@tahonermann I am unable to add you as a reviewer for some reason

[dvrogozh]

6.3.0 is already released. This this should be a next version, 6.3.1 or 7.0.0 depending on what the main (sycl) branch is currently tracking. Typically such versions are bumped immediately after the next release is done.

[tahonermann]

Ideally, the version information would somehow reflect the case when the source is not exactly the version claimed. I've seem some products adopt a .99 patch level number as an indicator of a pre-release build of the next version. If we like that approach, we could use 6.3.99 for now and bump it to 7.0.0 when we tag the repo for that release. Another possible option is to use a negative number (-1) for the patch level and use 7.0.-1 for now. I think that can be confusing though and potentially problematic if there is code that assumes unsigned values.

[dvrogozh]

I think -1 as a patch is a bad idea. This will drive some tools crazy :).

I don't have a strong preference regarding .99. You will still need to change that before each release. Some projects do that but I think mostly on CI level itself when building artifacts rather than in sources. For what I see in the ecosystem, typically version is stored as it will be in the next release and bumped once release is done in preparation for the next one.

[tahonermann]

I'm fine with just using the next release since we have a well-defined release cadence that keeps them predictable (for the foreseeable future).

We could also introduce a pre-release indicator that would be set to false as part of tagging the release and then set back to true with the release version bump. This would enable clang --version to report an indication of a pre-release build and avoid any ambiguity regarding whether a build really is or isn't the version it claims to be.

[dvrogozh]

@tahonermann what should be correct version in the tip of the sycl branch?

[tahonermann]

I'm assuming 7.0.0 (pre-release), but I'm not the right person to state that authoritatively.

[elizabethandrews]

I have modified the PR to have 7.0.0 (pre-release)

[mdtoguchi]

OK for driver

[YuriPlyakhin]

llvm/CMakeLists.txt change LGTM

[elizabethandrews]

I think I have addressed all review comments. The latest commit adds a pre-release indicator. The commit also changes the --version output with SYCL_BUILD_INFO to include version information

[premanandrao]

DPC++ Version Information is now stored in compiler source. clang --version will continue to display build information when local CI is used (i.e. SYCL_BUILD_INFO is defined), but will display in-source version otherwise.

cmake/Modules/DPCPPVersion.cmake should be updated to hold version information for each release.

Example Output:

DPC++ compiler 6.3.0 build based on:
clang version 23.0.0git (https://github.com/intel/llvm.git 5947c2aff087f88c90dcd56857405270ff0d4010)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: */releasebuild/bin
Build config: +assertion

Fixes: #21510 JIRA: 74112

Please remove Jira info from the description.

[premanandrao]

Looks okay to me.

[tahonermann]

This looks good to me. I added two comments that you can ignore or address in whatever way you feel is best. I don't need to review again.

[tahonermann]

I think this shouldn't be indented since it isn't within a conditional block.

Suggested change

	set(PRE_RELEASE 1)
	set(PRE_RELEASE 1)

[dvrogozh]

LGTM

[elizabethandrews]

DPC++ Version Information is now stored in compiler source. clang --version will continue to display build information when local CI is used (i.e. SYCL_BUILD_INFO is defined), but will display in-source version otherwise.
cmake/Modules/DPCPPVersion.cmake should be updated to hold version information for each release.
Example Output:

DPC++ compiler 6.3.0 build based on:
clang version 23.0.0git (https://github.com/intel/llvm.git 5947c2aff087f88c90dcd56857405270ff0d4010)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: */releasebuild/bin
Build config: +assertion

Fixes: #21510 JIRA: 74112

Please remove Jira info from the description.

@premanandrao the current guidelines allow us to mention the JIRA number without the link. I think it is useful to have this information in the log.

[elizabethandrews]

DPC++ Version Information is now stored in compiler source. clang --version will continue to display build information when local CI is used (i.e. SYCL_BUILD_INFO is defined), but will display in-source version otherwise.
cmake/Modules/DPCPPVersion.cmake should be updated to hold version information for each release.
Example Output:

DPC++ compiler 6.3.0 build based on:
clang version 23.0.0git (https://github.com/intel/llvm.git 5947c2aff087f88c90dcd56857405270ff0d4010)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: */releasebuild/bin
Build config: +assertion

Fixes: #21510 JIRA: 74112

Please remove Jira info from the description.

@premanandrao the current guidelines allow us to mention the JIRA number without the link. I think it is useful to have this information in the log.

I am not 100% certain though. I heard this in a call this week but I didn't verify with someone else. So I will remove it to be safe. Can someone else in this review weigh in just so I know.