Add generic Linux dev setup & bootstrap - #2035
Conversation
ac0faf9 to
3c56555
Compare
src/.vscode/tasks.json ran ./buildallprojects, and .gitattributes pinned line endings for the same file. Neither exists: the script came from the source-sdk-2013 import and never survived the move to CMake presets, so the task could only ever fail on invocation.
Five targets build with UNITY_BUILD ON, so the build's compile_commands.json lists only generated unity_*.cxx blobs and roughly 1300 translation units carry no compile flags an indexer can use - navigation and completion are dead across most of src/game. The script configures a second, build-free CMake directory with unity off, purely for its compile database. The property is cleared through a deferred CMAKE_PROJECT_neo_INCLUDE hook, so no tracked CMakeLists.txt changes and the build keeps its unity speedup. What it produces is editor-agnostic: compile_commands.json symlinked at the repo root, a .clangd removing the GCC-only flags clang rejects, and a pinned, checksummed clangd under .ide/ (the sniper image ships 13, too old for this tree's C++20). Entry points: the dev container (the CI image plus a non-root account matched to the local UID, so bind-mount files stay user-owned under rootful docker), the tracked VS Code tasks, or running the script directly. Everything generated is git-ignored; *.sh gains eol=lf so a Windows checkout cannot produce a script that fails to run.
3c56555 to
8c25c95
Compare
| # UNITY_BUILD so the database gets one entry per translation unit (see the | ||
| # header of tools/ntre-dev-setup.sh). The real build keeps its unity speedup. | ||
|
|
||
| function(_neo_ide_disable_unity dir) |
There was a problem hiding this comment.
This thing is kinda clever, but I think it would be better to create a CMake option NEO_USE_UNITY_BUILD instead and use its value to initialize the UNITY_BUILD property of all unity build targets. Set it to ON only for the CI build and OFF otherwise (which is what we need for Linux Debug (IntelliSense index only) preset and also the developers since the build is incremental). Apart from this - LGTM.
There was a problem hiding this comment.
Happy to make the change, thank you for the review!
There was a problem hiding this comment.
Done in 9f2a52c1 and 9b173e9a. One note on the "ON only for CI" part: rather than adding -DNEO_USE_UNITY_BUILD=ON to the workflow, the option defaults to ${NEO_CI_BUILD} (same pattern as NEO_GENERATE_GAMEDATA defaulting to NEO_DEDICATED), which covers both the Linux and Windows CI jobs with no workflow change. The IntelliSense preset sets it to OFF explicitly, and the injected override is gone. Happy to switch to an explicit workflow flag instead if you prefer it discoverable there.
D'oh, almost. Gotta' do another pass.
|
Note to self: I still need to toy around with Zed more to make sure this is solid. Note to self 2: Get more details on @Agiel 's specific Zed workflows to make sure I covered his concerns adequately. |
Description
Genericized IDE setup for Linux w/ Clang.
Optional developer tooling for working on the code, not a change to how NT;RE builds. Adds a dev container based on the same sniper SDK image the CI runners use, and
tools/ntre-dev-setup.sh, which sets up working C++ IntelliSense: a pinnedclangd, acompile_commands.jsonsymlinked at the repo root, and a.clangdwith the flags the SteamRT toolchain needs. Editor config for VS Code and Zed is written on request; everything generated is git-ignored, and the existing Qt Creator and CLI build workflows are untouched.Also removes two Source SDK leftovers: the
buildallprojectsgitattributes entry andsrc/.vscode/tasks.json, which both refer to a build script this tree no longer has.Trying it out
git clonethis repo and check out this branch..cppfile undersrc/and confirm go-to-definition and completion work.Requires Docker or Podman on the host. The README covers running the script outside a container.
Toolchain
Linked Issues
TODO