microsoft / microsoft/vscode-cmake-tools

Feature request - Customizable logging

Open
#3,179 1 comment 0 reactions 0 assignees View on GitHub
enhancement Feature: other help wanted
Dominant language
TypeScript
Stars
1.7k
Forks
546
Avg merge
2d 16h
Merged PRs (30d)
32

Description

### Brief Issue Summary

For the project I'm working on, it'd be great, if there was a way to customize log output location, format, and the way logging works. Afaik, logging right now saves ALL cmake configuration and build log outputs to the same \~/.local/share/CMakeTools/log.txt file since the installation of CMake Tools. What I want is:
- Option to save the output of the CMake configuration and the output of the build process to separate files.
- Option to make the name and the location of the buildlog and cmake configuration log (cmakelog) customizable.
- Option to enable/disable timestamping in the logfiles.
- Option to save new builds to separate cmakelog and buildlog files, and not append the output to the existing log file.

### CMake Tools Diagnostics

_No response_

### Debug Log

_No response_

### Additional Information

These options could be set in the settings.json file, for example:
"cmake.logConfiguration": {
"logfilePath": "\~/my/path/",
"logfileName": "mycmakelogname",
"logfileHandling": <"appendToExistingLogfile" || "keepPreviousLogfile" || "overwritePreviousLogfile" || "disableLogging" >,
"logTimeStamp":
}
"cmake.logBuild": {
"logfilePath": "\~/my/path/",
"logfileName": "mybuildlogname",
"logfileHandling": <"appendToExistingLogfile" || "keepPreviousLogfile" || "overwritePreviousLogfile" >,
"logTimeStamp":
}

What I want is, to be able to save only one cmake configuration output to one cmakelog file, and one build output to one buildlog file, to the location of the build directory. If a cmakelog or a buildlog exists there already, then rename the existing cmakelog or buildlog to cmakelog.prev or buildlog.prev, and then create the new cmakelog or buildlog (thus only keep the current and previous buildlog/cmakelog). This is very useful to compare the two cmakelog or buildlog with their corresponding *.prev outputs via kdiff3 or some other difftool.

Example for current behaviour:

- choose configure preset inside VSCode
- configuration with the chosen preset is executed, Makefiles are generated
- the output of the CMake configuration phase is appended to ~/.local/share/CMakeTools/log.txt
- choose build configuration preset
- press build
- build is executed
- the buildlog output is appended to ~/.local/share/CMakeTools/log.txt

Example for wished upon behaviour (**difference to the previous highlighted in bold**):

- choose configure preset inside VSCode
- configuration with the chosen preset is executed, Makefiles are generated
- **the output of the CMake configuration phase is logged to ~/path/to/build-directory/cmakelog. If there exists a cmakelog already, then rename that cmakelog to cmakelog.prev, and only then log the output to cmakelog, without timestamps (this behaviour can be customized via settings.json).**
- choose build configuration preset
- press build
- build is executed
- **the output of the build is logged to ~/path/to/build-directory/buildlog. If there exists a buildlog already, then rename that buildlog to buildlog.prev, and only then log the output to buildlog, without timestamps (this behaviour can be customized via settings.json).**

Contributor guide

Open the contributing guide

Research direction

No files, tests, or entry points are named in the issue. Start by locating the existing CMake configuration and build logging implementation, then compare its shared-file append behavior with the requested separate configurable logs, timestamp control, and previous-file rotation. Done means these settings work for both configuration and build output, including the requested file naming and handling modes.

Written by the indexing model from the issue text.

Assessment

Tech stack
cmake, typescript, vscode
Domain
build-system, developer-experience, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.