Critical

Overly broad version detection pattern (tools/buildsteps/windows/vswhere.bat:36)
The pattern findstr "18" will match any path containing "18", including potential false positives like "2018" or other paths with "18" in them. This could incorrectly identify non-VS2026 installations as VS2026.

Suggested fix: Use a more specific pattern like findstr "\\18\\" or findstr "2026" to match the actual VS2026 version marker, similar to how 2019 and 2022 are detected by their year.

Shouldn't have to touch the minimum. It's a minimum after all, not what's being used

Shouldn't have to touch the minimum. It's a minimum after all, not what's being used

Does it not matter that the 'Visual Studio 2026 18' generator doesn't exist in versions before 4.2??

Thanks for trying VS 2026.
docs\README.Windows.md needs some edits in the prerequisites and manual build,

I don't think BuildSetup.bat should be changed yet.

Thanks for trying VS 2026. docs\README.Windows.md needs some edits in the prerequisites and manual build,

I don't think BuildSetup.bat should be changed yet.

Agree. I've marked it as draft already.
I thought it would be helpful for people having a play (like me!) in the interim.
No hurry to merge.

Shouldn't have to touch the minimum. It's a minimum after all, not what's being used

Does it not matter that the 'Visual Studio 2026 18' generator doesn't exist in versions before 4.2??

No, because Kodi doesn't require 4.2

Adding support for VS 2026 is not the same as "forcing use VS 2026". As fuzzard says, the minimum requirements shouldn't change. Any changes should be optional and maintain backward compatibility (with VS 2022 at least).

Does it not matter that the 'Visual Studio 2026 18' generator doesn't exist in versions before 4.2??

not matter for use CMake 3.28 + VS 2022 (the minimum required)

If you want use use VS 2026 you need CMake 4.2 (not released yet)

Thanks for the clarification.

Critical

Overly broad version detection pattern remains unaddressed (tools/buildsteps/windows/vswhere.bat:36)
The pattern findstr "18" matches any path containing "18", causing false positives (e.g., "2018", "C:\Users\User18", directory names with "18"). This differs from the 2019/2022 detection which use full year strings.

Fix: Use findstr "2026" to match the pattern established by existing version checks (lines 32, 34).

Not necessary in this PR but as you are here maybe remove support of Visual Studio 2015 removing this block:

IF %vcvars%==no (
  FOR /f "usebackq tokens=1* delims=" %%i in (`%vswhere% -legacy -property installationPath`) do (
    ECHO %%i | findstr "14" >NUL 2>NUL
    IF NOT ERRORLEVEL 1 (
      IF EXIST "%%i\VC\vcvarsall.bat" (
        SET vcvars="%%i\VC\vcvarsall.bat"
        SET vsver=14 2015
      )
    )
  )
)

@thexai, thanks - done.

Shall I also simplify:

if "%PROCESSOR_ARCHITECTURE%" == "AMD64" (
  SET vcarch=x64
) else (
  rem arm host tools are only really working in VS 17 2022+
  rem fall back to x64 for older VS installations
  if "%vsvernumber%" GEQ "17" (
    rem PROCESSOR_ARCHITECTURE returns uppercase. Use powershell to
    rem lowercase for comparison and usage with vcvarsall.bat
    FOR /F "usebackq tokens=*" %%A IN (`powershell.exe -Command "('%PROCESSOR_ARCHITECTURE%').ToLower( )"`) DO SET vcarch=%%A
  ) else (
    SET vcarch=x64
  )
)

If VS 2022 is the minimum required.

@claude review.

Claude finished @78andyp's task —— View job

Code Review for PR #27473

• Read changed files and understand the changes
• Analyze code for issues and improvements
• Post review feedback

Summary

This PR adds Visual Studio 2026 support and removes VS 2015/2017 legacy support from vswhere.bat. The changes are straightforward and well-structured.

What's Good ✓

1. VS 2015 removal - The legacy -legacy fallback block for VS 2015 was correctly removed as requested by @thexai
2. ARM host tools simplification - The conditional logic for ARM host tools was appropriately simplified since VS 2022 is now the minimum supported version (lines 60-62)
3. Clean diff - The changes result in a more maintainable file with less conditional complexity

Issue to Address

VS 2026 detection pattern (line 36-37)

The current detection pattern findstr "\\18\\" is correct and addresses the earlier concern about false positives. This pattern specifically looks for \18\ in the path, which correctly matches the VS 2026 installation path structure:

C:\Program Files\Microsoft Visual Studio\18\Community

The escaped backslashes (\\18\\) correctly match the literal backslashes in the Windows path. This is better than findstr "2026" for VS 2026 because:

• VS 2019 uses 2019 in the path → findstr "2019" works
• VS 2022 uses 2022 in the path → findstr "2022" works
• VS 2026 uses 18 (toolset version) in the path, not 2026 → findstr "\\18\\" is the correct approach

One potential edge case to consider: If VS 2026's installation path actually contains 2026 instead of 18, then findstr "2026" would be needed instead. I'd recommend confirming the actual path structure in VS 2026 Preview. Based on @thexai's comment showing C:\Program Files\Microsoft Visual Studio\18\Community, the current implementation looks correct.

Minor Suggestion

Line 31 still defaults to SET vsver=15 2017 as a fallback. Since VS 2017 is no longer officially supported (VS 2022 is minimum), you might consider:

• Changing the default to 17 2022, or
• Adding a warning/error if neither 2019, 2022, nor 2026 is detected

This is a low-priority suggestion since the current behavior still works.

Verdict

The PR looks good and ready to merge once there's confirmation that the VS 2026 installation path structure uses 18 rather than 2026. The simplification of the ARM host tools logic is correct given VS 2022 as the minimum requirement.

@claude review

Claude finished @78andyp's task —— View job

Code Review for PR #27473

• Read changed files and understand the changes
• Analyze code for issues and improvements
• Post review feedback

Summary

This PR adds Visual Studio 2026 support and removes VS 2015/2017/2019 legacy support from vswhere.bat. The changes simplify the codebase significantly now that VS 2022 is the minimum supported version.

What's Good ✓

1. VS 2015 removal - The legacy -legacy fallback block for VS 2015 was correctly removed as requested by @thexai
2. VS 2017/2019 detection removal - Since VS 2022 is now the minimum, removing the 2017 and 2019 detection logic is appropriate
3. ARM host tools simplification - The conditional logic for ARM host tools was correctly simplified (lines 57-59) since VS 2022+ is now assumed
4. Clean diff - The changes result in a more maintainable file with less conditional complexity (-26 lines, +6 lines)

Issues to Address

1. VS 2026 detection pattern (lines 32-34)

The pattern findstr "\\18\\" is implemented to address the earlier concern about false positives. However, I want to verify the pattern logic:

• The pattern \\18\\ in a batch file's findstr will look for the literal string \18\ (the backslashes are escaped)
• This correctly matches paths like C:\Program Files\Microsoft Visual Studio\18\Community

This appears correct assuming VS 2026 uses 18 in its installation path rather than 2026. Based on @thexai's earlier comment confirming the path structure, this should work.

2. Inconsistent indentation (line 32)

    SET vsver=17 2022
	rem Default path for VS2026 does not include text 2026

Line 32 uses a tab character for indentation while the surrounding lines use spaces. This should be corrected for consistency:

    SET vsver=17 2022
    rem Default path for VS2026 does not include text 2026

3. Missing VS 2019 detection (potential issue)

The current implementation defaults to VS 2022 (SET vsver=17 2022) and only checks for VS 2026. If someone has VS 2019 installed (which uses version 16), this script will incorrectly report it as VS 2022.

However, since VS 2022 is now the minimum supported version, users with only VS 2019 should not be using this build system. You may want to add an explicit check/warning if an older VS version is detected, or document that VS 2019 is no longer supported.

Minor Suggestions

1. Comment clarity - The comment on line 32 could be more precise:

   rem VS2026 path uses version number (18) not year (2026)

Verdict

The PR is well-structured and achieves its goals. The main items to address are:

1. Required: Fix the inconsistent tab/space indentation on line 32
2. Optional: Consider if VS 2019 installations should produce a warning/error since it's no longer supported

Once the indentation is fixed, this should be ready to merge.

Jenkins build this please