-
Notifications
You must be signed in to change notification settings - Fork 464
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to open source file outside workspaceFolder from project outline #1504
Comments
@mutoo, can you provide a little more information for us? Which folder in the structure you shared is the |
@bobbrow, the |
Hi everyone, If I don't make any mistake, we are following a tutorial to create a sort of graphic engine on multiple platforms, using C++ and SDL: https://marcelbraghetto.github.io/a-simple-triangle/2019/03/02/part-02/ In this part, the author shows how to configure it's own VSCode instance using Cmake and Cmake Tools (vector-of-bool version, not from microsoft), but following the steps VSCode + extensions does not follow the rules and create another full path inside the current workspace folder. I expect that the configuration of the extensions change, or something we missed, because using the scripts on the console directly works, check the code directly and build the binary. Setup:
|
Hi @bobbrow, I also have this problem. I'm also using SDL like @k0pernicus, but I'm not following a tutorial (i.e. issue produced organically). For example, I might have a file structure like: EDIT: Updated this tree to reflect actual file structure since it may matter.
The add_library/add_executable call in CMakeLists could be using a relative or absolute path of SDL.h, and I still get the follow situation: Obviously C:\Users\Users doesn't exist: EDIT: Added relevant CMakeLists.txt content showing how I obtain the SDL.h path:
Setup: |
Would it be possible to receive a patch for this fix, it is blocking our entire workflow ... We have to switch IDE in order to edit our source files and switch back to run the CMake configuration. A workaround would also do the trick. |
I too would be very happy to have this fixed. If there is anything I can do to help, please reach out @bobbrow :-) |
Thanks for the offer @sleiner! If you have a repro and can debug the extension as it's building the tree view, that would help us get the information we need to understand the bug. Contribution doc The line I would set a breakpoint on is here: vscode-cmake-tools/src/tree.ts Line 232 in 48c4a33
I suspect that the |
Thanks for the helpful hint 😊 I actually came up with something that fixes the problem (at least on my Mac with a very simple project). I'll test it with a much larger project at work tomorrow 👍🏻 |
* Fix paths of target sources outside the workspace For more details, see: #1504 * Add test for source files outside of workspace root Co-Authored-By: Elson Wei <[email protected]> Co-authored-by: Elson Wei <[email protected]> Co-authored-by: Bob Brown <[email protected]>
@sleiner, your contribution is in 👍. If all goes according to plans, we should release CMake Tools 1.7.2 tomorrow. Until then, here's a vsix with your change, if needed: https://github.com/microsoft/vscode-cmake-tools/actions/runs/814930130. |
Thanks, you two 🙌🏻 |
* Fix typo in CMakePresets.json schema (#1809) MinSizRel => MinSizeRel * update version to 1.7.2 * Localize an error message * Added counts for presets (#1819) * override the locale when querying compiler versions (#1824) * Adopt new localization process (#1831) * Fix Operator Precedence when Getting Code Page (#1808) The replacing should happen after the "??" operator. Fixes #1615 Co-authored-by: Andreea Isac <[email protected]> * If we have both "-DCMAKE_GENERATOR:STRING=" and the generator from (#1753) toolchain, prefre using "-DCMAKE_GENERATOR:STRING=", as "-DCMAKE_GENERATOR:STRING=" can be defined by different cmake-variants.yaml Signed-off-by: Yonggang Luo <[email protected]> Co-authored-by: Andreea Isac <[email protected]> * Use stricter type checks in presets expansion (#1818) * Use stricter type checks in presets expansion * Resolving comments Co-authored-by: Andreea Isac <[email protected]> * Fix paths of target sources outside the workspace (#1816) * Fix paths of target sources outside the workspace For more details, see: #1504 * Add test for source files outside of workspace root Co-Authored-By: Elson Wei <[email protected]> Co-authored-by: Elson Wei <[email protected]> Co-authored-by: Bob Brown <[email protected]> * CHANGELOG updates for 1.7.2 (#1837) Co-authored-by: BlueC0re <[email protected]> Co-authored-by: Bob Brown <[email protected]> Co-authored-by: Bob Brown (DEVDIV) <[email protected]> Co-authored-by: xisui-MSFT <[email protected]> Co-authored-by: Colen Garoutte-Carson <[email protected]> Co-authored-by: Huang, Zhaoquan <[email protected]> Co-authored-by: Yonggang Luo <[email protected]> Co-authored-by: Simon Leiner <[email protected]> Co-authored-by: Elson Wei <[email protected]>
hi @bobbrow, I am using 1.4.2 CMake Tools on macOS, but the issue is still there:
The project structure looks like:
with this simple setup:
As you can see, the error reports a path with
<CMakeLists Dir>+<Absolute Source Path>
, which is duplicate and totally wrong.Platform and Versions
Operating System:macOS
CMake Version:3.18.4
VSCode Version:1.50.1
CMake Tools Extension Version: 1.4.2
Compiler/Toolchain: Clang 11
Originally posted by @mutoo in #1254 (comment)
The text was updated successfully, but these errors were encountered: