[Bug]: sdktools extension was not compiled in the mock test

[F1F88]

Prerequisites

• I have checked that my issue doesn't exist yet in the issue tracker

Operating System and Version

Windows 11 24H2

Game / AppID and Version

NMRiH 1142

SourceMod Version

1.13.0.7366

Metamod:Source Version

1.12.0-dev+1219

Version Verification

• I have updated SourceMod to the latest version and the issue persists
• I have updated SourceMod to the latest snapshot and the issue persists
• I have updated Metamod:Source to the latest snapshot and the issue persists

Updated SourceMod Version

No response

Updated Metamod:Source Version

No response

Description

In the mock test workflow running in .github/workflows/mocktest.yml, SourceMod uses --sdks=mock for building, but extensions/sdktools/AMBuilder explicitly skips the mock SDK build on line 32:

https://github.com/alliedmodders/sourcemod/blob/master/extensions/sdktools/AMBuilder#L32-L33

This means that sdktools.ext will not be compiled at all during the CI mock test process, causing test plugins that depend on sdktools to fail to load or run.

Possibly related:

• Get sdktools and sdkhooks/dhooks to load on hl2sdk-mock #1892
• ae4e043

Steps to Reproduce

No response

Relevant Log Output

[psychonic]

There's only one test plugin that currently relies on sdktools, and it doesn't necessarily need to. (We could rework that loop to just loop from 0 to max ents rather than using FindEntityByClassname) and avoid having to stub out all of the interfaces used by sdktools that aren't used by core.

Was there any other specific use case for this?

[F1F88]

There's only one test plugin that currently relies on sdktools, and it doesn't necessarily need to. (We could rework that loop to just loop from 0 to max ents rather than using FindEntityByClassname) and avoid having to stub out all of the interfaces used by sdktools that aren't used by core.

Was there any other specific use case for this?

I also tested this in my own mock test setup by removing the mock exclusion from extensions/sdktools/AMBuilder.

SourceMod builds successfully and the test suite runs successfully with SDKTools built against hl2sdk-mock. I haven't found any other issue caused by building SDKTools for the mock SDK.

In fact, removing the exclusion also gets rid of a number of noisy errors during the mock test run:

[SM] Unable to load extension "sdktools.ext": ../gamedir/addons/sourcemod/extensions/x64/sdktools.ext.so: cannot open shared object file: No such file or directory
[SM] Unable to load plugin "playercommands.smx": Required extension "SDKTools" file("sdktools.ext") not running
[SM] Unable to load plugin "basecomm.smx": Required extension "SDKTools" file("sdktools.ext") not running
[SM] Unable to load plugin "funcommands.smx": Required extension "SDKTools" file("sdktools.ext") not running
[SM] Unable to load plugin "funvotes.smx": Required extension "SDKTools" file("sdktools.ext") not running

These errors appear to be a direct consequence of SDKTools not being built, rather than actual test failures.

I haven't found a use case where SDKTools needs to be excluded from the mock build. If there is a specific reason for the exclusion, I'd be interested to know what it is.

My preference would therefore be to remove the mock exclusion from extensions/sdktools/AMBuilder. It seems cleaner to build SDKTools as part of the mock SDK test environment rather than leave the extension unavailable and work around the resulting plugin load failures.

If there is a valid technical or historical reason why SDKTools must not be built for hl2sdk-mock, I'm also happy to take the alternative approach and modify the one test plugin that currently depends on SDKTools.

[dvander]

My recollection is that SDKTools needed a bunch of stuff in the SDK that I wasn't prepared to stub out. If you have a patch to get it building, please feel free to submit it, I'll take it.

[peace-maker]

See #2558 which restores the hl2sdk-mock tests and fixes this issue. Having sdktools available is useful to get sdkhooks to load to get dhooks to load, which can be useful to test the dynamic hooking capabilities. sdktools already compiles fine.