fix/feat: CLion 2026 compatibility (Ktor crash, silent build failures) & CMake support

[Nightwing-007]

This PR bundles three focused commits to restore compatibility with recent JetBrains IDE updates (specifically tested on CLion 2026.1) and improve the workflow for CMake users.

1. Fix: Ktor ServiceConfigurationError crash

In modern JetBrains IDEs, strict PluginClassLoader boundaries cause Ktor's default ServiceLoader to fail when initializing HttpClient().

• Change: Explicitly passed the engine HttpClient(Java.create()) to bypass the ServiceLoader entirely, preventing the hard crash on problem import.

2. Fix: Silent build failures in ProcessRunner

Previously, ProcessRunner only checked if stderr was empty to determine compilation success. If a compiler (like MSYS2 g++) failed silently due to missing system PATH dependencies, it exited with code 1 but empty stderr, causing AutoCp to falsely report success and crash looking for the executable.

• Change: Updated ProcessRunner to strictly evaluate the process exitCode. It now properly reports silent failures back to the user.

3. Feat: @projectDir and @name macros for CMake support

AutoCp's internal build pipeline bypasses IDE build systems. For CLion users, this meant AutoCp couldn't find binaries generated in cmake-build-debug.

• Change: Added @projectDir and @name macros to AutoCpKeys and Lang.kt. Users can now clear the buildCommand and set executeCommand to "$projectDir/cmake-build-debug/@name.exe", allowing seamless integration with CMake.

Let me know if you need any adjustments to these commits

[znzryb]

One structural request first: would you mind splitting this into separate PRs? A crash fix, a build-failure fix and a new feature each need a different discussion, and bundling them holds the uncontroversial parts hostage to the rest.

1. Ktor crash: HttpClient(Java) already passes the engine factory explicitly — that line came from #174, which fixed this same ServiceConfigurationError — so the ServiceLoader shouldn't be involved since v0.10.0. Could you post the actual stack trace you hit on CLion 2026.1? If it still crashes with the factory form, something else is failing and we'd want to see it before switching to Java.create().

2. Exit-code check: the silent-build-failure motivation makes sense, but ProcessRunner.run is also used for the solution, generator and checker processes, and those callers already interpret exit codes themselves — e.g. Judge.kt maps a checker's non-zero exit codes to WA/PE verdicts, so throwing RuntimeErr inside run() would break checker-based judging. The build step's call site (TwoStepProcessFactory) would be the right home for this check — and since #178 is already reworking these exact lines in readOutputAsync, it'd be better coordinated there than landed twice.

3. @projectDir/@name macros: AutoCp compiling into its own isolated directory looks intentional rather than a limitation — it keeps test runs independent of the IDE's build state. With buildCommand cleared, AutoCp would run whatever binary CLion last produced in cmake-build-debug, so after editing the solution you could silently test a stale executable unless you remember to rebuild through CMake first. We'd rather not trade that guarantee away for this workflow.

[Nightwing-007]

Closing to split these into smaller, focused PRs as discussed

[Nightwing-007]

Thanks for taking the time to review this so thoroughly. Your points make perfect sense, especially regarding the checker-based judging and the risk of testing stale CMake executables. I completely agree with your architectural calls here. I will close the bundled PR (#177) and split the relevant fixes into separate PRs. Regarding Point 1 (the Ktor crash), *I have attached the exact stack trace I hit* on CLion 2026.1.4 (Windows 11) immediately upon importing a problem. It looks like the ServiceConfigurationError is failing on the CIOEngineContainer SPI lookup during GoogleAnalytics initialization. For Point 2 (the silent build failure check), I see exactly what you mean about breaking Judge.kt. I will scope the exit-code check strictly to the compilation step inside TwoStepProcessFactory (and I will look at #178 to ensure I don't step on any toes in readOutputAsync). For Point 3, I'll drop the @projectdir feature entirely to preserve the isolated build guarantees. I'll get the newly scoped PRs up shortly. Thanks again for the guidance! Best regards, Deepakraj

On Sat, Jul 25, 2026 at 2:47 PM znzryb ***@***.***> wrote: *znzryb* left a comment (Pushpavel/AutoCp#177) <#177 (comment)> One structural request first: would you mind splitting this into separate PRs? A crash fix, a build-failure fix and a new feature each need a different discussion, and bundling them holds the uncontroversial parts hostage to the rest. *1. Ktor crash:* HttpClient(Java) already passes the engine factory explicitly — that line came from #174 <#174>, which fixed this same ServiceConfigurationError — so the ServiceLoader shouldn't be involved since v0.10.0. Could you post the actual stack trace you hit on CLion 2026.1? If it still crashes with the factory form, something else is failing and we'd want to see it before switching to Java.create(). *2. Exit-code check:* the silent-build-failure motivation makes sense, but ProcessRunner.run is also used for the solution, generator and checker processes, and those callers already interpret exit codes themselves — e.g. Judge.kt maps a checker's non-zero exit codes to WA/PE verdicts, so throwing RuntimeErr inside run() would break checker-based judging. The build step's call site (TwoStepProcessFactory) would be the right home for this check — and since #178 <#178> is already reworking these exact lines in readOutputAsync, it'd be better coordinated there than landed twice. *3. @***@***.*** macros:* AutoCp compiling into its own isolated directory looks intentional rather than a limitation — it keeps test runs independent of the IDE's build state. With buildCommand cleared, AutoCp would run whatever binary CLion last produced in cmake-build-debug, so after editing the solution you could silently test a stale executable unless you remember to rebuild through CMake first. We'd rather not trade that guarantee away for this workflow. — Reply to this email directly, view it on GitHub <#177?email_source=notifications&email_token=BMCVMKLZ6TWQO5DDHVZUQF35GR3K3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBXG44TKOBXGQ4KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5077958748>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BMCVMKNHOUNNLEO5PTTKBPL5GR3K3AVCNFSNUABFKJSXA33TNF2G64TZHMZTOMRQGE2TAMJSHNEXG43VMU5TIOBYGE4DGOJWG432C5QC> . You are receiving this because you authored the thread.Message ID: ***@***.***>

java.util.ServiceConfigurationError: io.ktor.client.HttpClientEngineContainer: io.ktor.client.engine.cio.CIOEngineContainer not a subtype at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:559) at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1115) at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1142) ... [abbreviated] at io.ktor.client.HttpClientJvmKt.<clinit>(HttpClientJvm.kt:39) at com.github.pushpavel.autocp.common.analytics.GoogleAnalytics.<init>(GoogleAnalytics.kt:25) at com.github.pushpavel.autocp.common.analytics.GoogleAnalytics.<clinit>(GoogleAnalytics.kt:62) at com.github.pushpavel.autocp.common.analytics.listeners.ProblemGatherListener.onGenerated(ProblemGatherListener.kt:14)