${fileDirname} not working as a predefined variable

[Azthenix]

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]

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]

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

[Azthenix]

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.

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]

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]]

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]]

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

[rustamabdullaev-maandag]

${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]

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]

${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]

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

[mcowpert]

@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]

Hm, following up on the above as I experiment:

• ${workspaceFolder} (alone) is not so useful because that's the default root of a directory: "main/libraries" is equivalent to "${workspaceFolder}/main/libraries". (Not using multi-root here, so I'm unsure about ${workspaceFolder:ROOTID}.)
• a path with, e.g., **/inc is also evidently not supported, so time spent spec'ing out specific but common subfolder names (such as include) is wasted. I guess we just let Intellisense figure it out.

[sean-mcmanus]

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

[bobbrow]

@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]

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]

@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.