Split out from nlmixr2/nlmixr2#408, where this wording cost several round-trips of diagnosis.
Summary
When model compilation fails, .badBuild() in R/rxode2.R unconditionally blames the user's toolchain, regardless of why the build failed. If the failure is an rxode2 codegen bug (invalid C emitted), the message points the user in exactly the wrong direction and never shows the compiler error that would identify the real problem.
R/rxode2.R:2062-2071:
message("Error building the model: see rxode2::rxLastCompile()")
.rxCompileEnv$success <- FALSE
if (.Platform$OS.type == "windows") {
message("this could be because your Rtools is not set up correctly")
} else {
message("please make sure you have a working C compiler set up")
}
message("you may use nlmixr2::nlmixr2CheckInstall() to help diagnose installation issues")
stop(msg, call. = FALSE)Why this matters
In #408 the actual cause was a codegen defect (raw ETA[n]/THETA[n] leaking into the generated C — see the companion issue). The user's toolchain was fine. But because the message said Rtools, the thread spent three exchanges on nlmixr2CheckInstall() output and R versions — all of which came back clean — while the compiler's own diagnostic sat unread inside rxLastCompile()$stderr:
error: 'ETA' undeclared (first use in this function)
error: 'THETA' undeclared (first use in this function)
That one line identifies the bug immediately.
Suggested improvement
Surface the compiler stderr (at least the error: lines) directly, and reserve the toolchain advice for cases where it is plausible. Roughly:
- If
.out$stderr contains compiler error: lines, print the first few of them.
- Emit the "undeclared identifier" / codegen-bug signature as "this looks like an rxode2 code generation problem; please report it with
rxode2::rxLastCompile()" rather than as a toolchain problem.
- Keep the Rtools /
nlmixr2CheckInstall() hint for the cases it actually fits — e.g. compiler not found, make missing, non-zero status with no compiler diagnostics at all.
Even the minimal version — always echoing the compiler's error: lines — would have short-circuited #408 on the first post, and would help users self-diagnose genuine toolchain breakage too.
Environment
Split out from nlmixr2/nlmixr2#408, where this wording cost several round-trips of diagnosis.
Summary
When model compilation fails,
.badBuild()inR/rxode2.Runconditionally blames the user's toolchain, regardless of why the build failed. If the failure is an rxode2 codegen bug (invalid C emitted), the message points the user in exactly the wrong direction and never shows the compiler error that would identify the real problem.R/rxode2.R:2062-2071:Why this matters
In #408 the actual cause was a codegen defect (raw
ETA[n]/THETA[n]leaking into the generated C — see the companion issue). The user's toolchain was fine. But because the message said Rtools, the thread spent three exchanges onnlmixr2CheckInstall()output and R versions — all of which came back clean — while the compiler's own diagnostic sat unread insiderxLastCompile()$stderr:That one line identifies the bug immediately.
Suggested improvement
Surface the compiler stderr (at least the
error:lines) directly, and reserve the toolchain advice for cases where it is plausible. Roughly:.out$stderrcontains compilererror:lines, print the first few of them.rxode2::rxLastCompile()" rather than as a toolchain problem.nlmixr2CheckInstall()hint for the cases it actually fits — e.g. compiler not found,makemissing, non-zero status with no compiler diagnostics at all.Even the minimal version — always echoing the compiler's
error:lines — would have short-circuited #408 on the first post, and would help users self-diagnose genuine toolchain breakage too.Environment