search

microsoft / vscode-cpptools

Official repository for the Microsoft C/C++ extension for VS Code.
Other
5.51k stars 1.55k forks source link

${fileDirname} not working as a predefined variable #6025

Open Azthenix opened 4 years ago

Azthenix commented 4 years ago

Issue Type: Bug

First time reporting an issue here so pardon if I do something wrong.

I don't know how to reproduce the bug because I don't really know what caused it or if it was already there in the first place.

So I tried to setup my VSCode for C projects with MinGW on windows and tried to use the ${fileDirname} to set it up on the c_cpp_properties.json.

But it doesn't show as a path and it only shows as ${fileDirname} in C/C++ Configurations UI and it reports that "Cannot find: ${fileDirname}".

Extension version: 0.29.0 VS Code version: Code 1.48.1 (3dd905126b34dcd4de81fa624eb3a8cbe7485f13, 2020-08-19T17:12:13.244Z) OS version: Windows_NT x64 10.0.18363

System Info |Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i3-7020U CPU @ 2.30GHz (4 x 2304)| |GPU Status|2d_canvas: enabled
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
oop_rasterization: disabled_off
protected_video_decode: enabled
rasterization: enabled
skia_renderer: disabled_off_ok
video_decode: enabled
viz_display_compositor: enabled_on
viz_hit_test_surface_layer: disabled_off_ok
webgl: enabled
webgl2: enabled| |Load (avg)|undefined| |Memory (System)|3.84GB (0.54GB free)| |Process Argv|| |Screen Reader|no| |VM|0%|
sean-mcmanus commented 4 years ago

We haven't implemented support for that variable yet. See https://github.com/microsoft/vscode-cpptools/blob/master/Extension/src/common.ts#L348 for variables that are currently handled. It works in tasks.json and launch.json though.

If you can provide an example of how you intend to use ${fileDirname} in c_cpp_properties.json we could make sure that that case is handled.

sean-mcmanus commented 4 years ago

https://github.com/microsoft/vscode-cpptools/issues/5625 is a closely related issue.

Azthenix commented 4 years ago

It works in tasks.json and launch.json though.

I noticed this as well.

If you can provide an example of how you intend to use ${fileDirname} in c_cpp_properties.json we could make sure that that case is handled.

"includePath": [
    "${workspaceFolder}",
    "${fileDirname}/includes"
]

I want to be able to run and debug the file with the specific includes of the project folder and also be able to quickly switch between projects without changing my workspace.

image For example, in this picture I have a 'C' folder as the workspace folder and 'sampleProjectFolder' as the project directory. I want to be able to include files from the 'includes' folder to the 'main.c' file.

denchat commented 3 years ago

I think some commit just decided to break it somewhere in the arrow of time.

Perhaps this implies encouraging the workspaceFolder usage instead. ¯\_(ツ)_/¯

github-actions[bot] commented 3 years ago

This feature request is being closed due to insufficient upvotes. When enough upvotes are received, this issue will be eligible for our backlog.

github-actions[bot] commented 2 years ago

This feature request has received enough votes to be added to our backlog.

rustamabdullaev-maandag commented 2 years ago

${fileDirname} is useful for complex projects in which a Makefile can't be parsed properly, whereas a simple includePath like ${fileDirname}/../inc could solve the issue.

Please add support for ${fileDirname} in c_cpp_properties.json.

tlunet commented 2 years ago

I would also be interested in such feature : for a course on C++, each of my student provides there exercise solutions in a git repository, and I have a script that automatically update those in a global vscode workspace, where each student code is in a sub-folder. Since most solutions use similar header names (they have the same exercise task), the solution using recursive include path is not very appropriate, since it induces a confusion between the ~60 submitted solutions. But a file-dependent include using ${fileDirname}/../include or something similar would be the perfect fit !

PS : could be great for students too, since they have different exercise tasks in the same vscode workspace, and some tasks use similar header files (when the next exercise is an evolution of the previous exercise task)

BellettiR commented 2 years ago

${fileDirname} is useful for complex projects in which a Makefile can't be parsed properly, whereas a simple includePath like ${fileDirname}/../inc could solve the issue.

Please add support for ${fileDirname} in c_cpp_properties.json.

that is exactly what I'm trying to achieve in my project :)

sean-mcmanus commented 2 years ago

Is there a reason using #include "" is not sufficient? That should automatically add the current directory to the include path.

mcowpert commented 1 year ago

@sean-mcmanus I am puzzled by your comment. This ticket is, I believe, about setting includePath in c_cpp_properties.json for the purposes of Intellisense. The text you propose is not valid for JSON; but even in a C/C++ file, I think the empty string is invalid.

Our source tree at work is a nasty result of two merged companies' sources, and those companies used conflicting (and not always internally consistent) layouts. Some projects have separate src and inc, some have .cpp and .h all in the same folder. Most but not all #include statements specify only the filename, no relative paths. For the purposes of any given source, the priority search should be the current folder, then that folder's peer ../inc; otherwise it should fall back to the more global spec used to resolve cross-project includes. What I am wondering is whether Intellisense's searching even knows to look in locations relative to current file. If the net search path is constructed at load time (?) then the equivalent of "." and ".." in includePath don't add useful information to that net search path. If I enter "../Inc" to the JSON file, it shows a parsing error: "Cannot find /my/workspace/parent/Inc", which is true.

mcowpert commented 1 year ago

Hm, following up on the above as I experiment:

sean-mcmanus commented 1 year ago

@mcowpert I was referring to using "" instead of <> for the #include (not actually an empty string).

bobbrow commented 1 year ago

@mcowpert I was referring to using "" instead of <> for the #include (not actually an empty string).

... because when you include with "" IntelliSense will automatically add the path to the current file to the include path, whereas <> does not.

https://stackoverflow.com/questions/3162030/difference-between-angle-bracket-and-double-quotes-while-including-heade

jussihi commented 1 year ago

Wow, this is still not supported. Well, this feature request will get an upvote from me :) (working ${fileDirname} variable in c_cpp_properties.json.)

Swiftkill commented 10 months ago

@mcowpert I was referring to using "" instead of <> for the #include (not actually an empty string).

... because when you include with "" IntelliSense will automatically add the path to the current file to the include path, whereas <> does not.

https://stackoverflow.com/questions/3162030/difference-between-angle-bracket-and-double-quotes-while-including-heade

As it should because <> are for system\platform\external headers and "" are for project's header files and compiler behavesin same way: <> doesn't use local folder, "" uses it. If header not found at path of current file, both compiler and IntelliNonsense should continue look up through other given folders.

Tbh, the recent style of separating internal headers from .cpp files is misguided mimicking of Micrsoft style, where they most of the time work with projects which got some public headers (for API), and such structure requires to jump hoops with command-line build tools, because language's rules were written with opposite in mind.