[WIP] build: preserve explicit output names

[visualfc]

Summary

• preserve the exact output path specified with -o
• skip build-mode prefix and extension rewriting for explicit output files
• keep existing default naming conventions when -o is not specified
• derive generated C header names from the actual output extension

Testing

• go test ./internal/build -run 'TestApplyBuildModeNaming|TestBuildOutFmtsBuildModes|TestBuildOutFmtsPCLN| TestTestOutputFileLogic' -count=1

[fennoai]

Review: preserve explicit output name

The change correctly makes an explicit -o name authoritative for single-package ModeBuild (and file-path ModeTest): buildOutputPath now short-circuits to conf.OutFile verbatim, skipping the lib prefix / extension normalization in applyPrefix. This matches go build -o semantics and the added tests (exe_preserve_outfile_lib_prefix, c_shared_build_with_outfile, c_archive_build_with_outfile_without_extension) lock the intended behavior in well.

The build.go change from conf.AppExt to filepath.Ext(outFmts.Out) for libname is a necessary follow-on and a genuine fix: with an explicit -o custom.so on darwin (where AppExt=".dylib"), the old code would not have trimmed .so and would produce custom.so.h; the new code correctly yields custom.h.

A few non-blocking cleanups worth considering (inline). Nothing blocking.

Additional notes (no reliable inline location):

• Behavior is user-visible: with an explicit -o, no lib prefix is added and no extension is appended (user owns the exact name). doc/Embedded_Cmd.md:5 documents -o <file> only as "Specify output file name" — consider a one-line note that the explicit name is now used as-is, to match go build semantics.
• Test coverage gaps: no end-to-end buildOutFmts test exercises the new early-return for ModeTest with an explicit file path, nor the multiPkg && OutFile != "" build case (which intentionally falls through to temp-file generation rather than honoring the early return). Pinning those boundaries would guard against regressions.

Additional findings

• internal/build/outputs.go:71: [P2] determineBaseNameAndDir ModeBuild+OutFile branch is now dead work: For single-package ModeBuild with conf.OutFile != "", buildOutputPath now early-returns conf.OutFile verbatim (line 145) before buildOutFmts ever uses the baseName/dir this branch produces. So the AppExt trimming, filepath.Dir split, and "."->"" normalization here are computed but discarded. Consider simplifying this branch to return pkgName, "" (or removing it) and letting buildOutputPath own the explicit--o case, so a future reader isn't misled into thinking this still drives the build -o path.
• internal/build/outputs.go:86: [P2] Stale comment: ModeTest baseName/dir now discarded by early return: For the explicit-file ModeTest case (not a dir, not ending in /), buildOutputPath also early-returns conf.OutFile verbatim (lines 143-144), so the baseName/dir computed here are discarded. The comment on lines 84-85 ("Don't convert '.' to '' ... This preserves the information that user specified an output file") describes a mechanism that no longer has any effect. Update the comment or remove this now-moot computation.

[codecov]

Codecov Report

❌ Patch coverage is 85.71429% with 3 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
internal/build/outputs.go	88.23%	1 Missing and 1 partial ⚠️
internal/build/build.go	75.00%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[github-actions]

LLGo baseline benchmarks

3e8bf4eef8f2 | workflow run | long-term charts

Program measurements

Platform	Workload	File size	vs base	Build	vs base	Run	vs base
Linux	cprintf	19288 B	0 B / +0.0%	352.990 ms	+25.43 ms / +7.8% (worse)	1.315 ms	-74.82 us / -5.4% (better)
Linux	fmtprintf	1859320 B	0 B / +0.0%	2.676 s	-4.343 ms / -0.2% (better)	3.235 ms	+21.56 us / +0.7% (worse)
Linux	println	68776 B	0 B / +0.0%	335.991 ms	+2.141 ms / +0.6% (worse)	1.588 ms	-72.99 us / -4.4% (better)
macOS	cprintf	84672 B	0 B / +0.0%	439.784 ms	-36.25 ms / -7.6% (better)	3.539 ms	-51.04 us / -1.4% (better)
macOS	fmtprintf	1892448 B	0 B / +0.0%	3.374 s	+875.8 ms / +35.1% (worse)	13.750 ms	+1.042 ms / +8.2% (worse)
macOS	println	121360 B	0 B / +0.0%	395.750 ms	-41.23 ms / -9.4% (better)	3.586 ms	-970.4 us / -21.3% (better)

Core language and compiler benchmarks

Platform	Benchmark	ns/op	vs base
Linux	BenchmarkLookupPCRandom	13.220 ns/op	-0.02 ns/op / -0.2% (better)
Linux	BenchmarkMergeCompilerFlags	151.200 ns/op	+0.1 ns/op / +0.1% (worse)
Linux	BenchmarkMergeLinkerFlags	96.420 ns/op	+1.75 ns/op / +1.8% (worse)
Linux	BenchmarkChannelBuffered	34.010 ns/op	-0.02 ns/op / -0.1% (better)
Linux	BenchmarkChannelHandoff	30506 ns/op	+1619 ns/op / +5.6% (worse)
Linux	BenchmarkDefer	46.050 ns/op	+0.34 ns/op / +0.7% (worse)
Linux	BenchmarkDirectCall	1.557 ns/op	0 ns/op / +0.0%
Linux	BenchmarkGlobalRead	1.559 ns/op	+0.002 ns/op / +0.1% (worse)
Linux	BenchmarkGlobalWrite	2.481 ns/op	+0.001 ns/op / +0.04032% (worse)
Linux	BenchmarkGoroutine	33987 ns/op	-273 ns/op / -0.8% (better)
Linux	BenchmarkInterfaceCall	8.097 ns/op	-0.003 ns/op / -0.03704% (better)
Linux	BenchmarkRuntimeGetG	2.180 ns/op	0 ns/op / +0.0%
macOS	BenchmarkLookupPCRandom	12.010 ns/op	-8.71 ns/op / -42.0% (better)
macOS	BenchmarkMergeCompilerFlags	132 ns/op	-38.6 ns/op / -22.6% (better)
macOS	BenchmarkMergeLinkerFlags	80.050 ns/op	-31.55 ns/op / -28.3% (better)
macOS	BenchmarkChannelBuffered	26.750 ns/op	+0.9 ns/op / +3.5% (worse)
macOS	BenchmarkChannelHandoff	7015 ns/op	-3215 ns/op / -31.4% (better)
macOS	BenchmarkDefer	38.630 ns/op	-3.25 ns/op / -7.8% (better)
macOS	BenchmarkDirectCall	1.205 ns/op	+0.042 ns/op / +3.6% (worse)
macOS	BenchmarkGlobalRead	1.207 ns/op	+0.088 ns/op / +7.9% (worse)
macOS	BenchmarkGlobalWrite	1.194 ns/op	-0.002 ns/op / -0.2% (better)
macOS	BenchmarkGoroutine	31342 ns/op	-1458 ns/op / -4.4% (better)
macOS	BenchmarkInterfaceCall	5.300 ns/op	+0.114 ns/op / +2.2% (worse)
macOS	BenchmarkRuntimeGetG	2.777 ns/op	-0.392 ns/op / -12.4% (better)

Compared with cf91afb98fca measured in the same runner job.