Makefile entry point not found

[igenyar]

I have Makefile Tools installed on VM (192.168.1.233).

On VM, I have the source code of qpid-cpp. I set up build directory (bld) then run cmake. Below is the configuration.

{
    "editor.fontSize": 22,
    "workbench.editorAssociations": {
        "*.ipynb": "jupyter.notebook.ipynb"
    },
    "python.pythonPath": "C:\\Program Files\\Python38\\python.exe",
    "makefile.makefilePath": "/home/user/src/qpid-cpp-1.39.0/bld/",
    "files.trimTrailingWhitespace": true,
    "python.defaultInterpreterPath": "C:\\Program Files\\Python38\\python.exe",
    "workbench.colorTheme": "Visual Studio Dark",
    "remote.SSH.remotePlatform": {
        "192.168.1.233": "linux"
    },
    "makefile.makePath": "/usr/bin/make",
    "makefile.launchConfigurations": [
        
    
    ]
}

I have verified there is Makefile under bld and I can run make through command line. However, it keeps complaining.

[andreeis]

@igenyar, I just looked at the code and indeed we don't automatically append "Makefile" or "makefile" to the "makefile.makefilePath" in case that is only a folder. We do this automatic append in some other cases (-C related). So indeed we can improve on this and I will leave this work item open.

But you can easily write the makefile name yourself so that we read a complete full path. If that doesn't work then it's higher priority for us to fix.

[maciejmatczak]

I have this plugin installed, as some of my projects have Makefiles. Mainly for Intellisense purposes.

But for every other projects, I do get this popup.

From my POV, it would be nice if this extension would follow some kind of initialization flow (like Python extension - initialized on first Python file opened).

No Makefile in my repository? Please don't bother users with a popups. Thanks for consideration!

[mvrahden]

+1 for this one. Please fix this if possible. It happens in multi-root workspaces

[andreeis]

@maciejmatczak and @mvrahden, are you saying that you see this popup also when there is absolutely no makefile present anywhere inside the location that you open as folder in VSCode? That would be a bug.
Otherwise, if you do have some makefile files somewhere in there (maybe for tests, or...) the extension gets activated by design, after which we start searching for one in the root folder or read the "makefile.makefilePath" setting, which is also by design. There are variations of ideas to notify the user without the popup, we can definitely do that and make this less annoying for you or (after you confirm my above question which would be a different issue) we can implement a one time silencer button (like "Create/Locate/Ignore" popup of CMake Tools, if you happen to be familiar with that similar and older extension).
I thought I opened a different issue to track the "silencer UI" approach but until I find it I will leave this one opened.

[maciejmatczak]

99% that's the case, most probably I do have Makefile somewhere in the repo...

Now, that's funny ;). So extension does find the Makefile, so it gets activated... and then notifies me that it cannot find the Makefile, eh? :D

Silencer sounds OK. Also, "strict activation" for me sounds even better! Activate only if makefile.makefilePath's Makefile path is found. That, for me, would be a fair condition under which I would like to see that specific popup.

[andreeis]

@maciejmatczak, unfortunately, for now VSCode itself does not support an activation scenario about evaluating a setting ("makefile.makefilePath"). If we activate only based on a makefile being in the root, then the users who need to set the setting will have to activate manually. If we activate based on any makefile anywhere in the folder structure, we have the problem you see. The silencer will be the best compromise.

[thediveo]

I work with multiroot workspaces as well as Go workspaces; I have multiple per Go-module (Workspace subfolder) Makefiles. This even doesn't seem to be currently covered by this plugin? Maybe being able to disable this plague-in for such projects might be helpful, but then I will loose the intellisense help when I need to work on individual Makefiless.

[andreeis]

@thediveo, indeed we don't support multiroot workspaces yet in the Makefile Tools extension but, so that you don't lose IntelliSense, you an apply the workaround described here: #90.

The workaround was not perfect for the users who also wanted to build (more specifically, clean one project as opposed to all) but since you don't build anyway (you were willing to disable the extension completely) that workaround is enough to get full IntelliSense for your code base. Try that and let us know if you encounter any issues. We can help get you unblocked.

[thediveo]

@thediveo, indeed we don't support multiroot workspaces yet in the Makefile Tools extension but, so that you don't lose IntelliSense, you an apply the workaround described here: #90.

Yes, that does the trick. Thank you very much for making me aware of this workaround. Of course, I would still like to see the full workspace support landing, but at least one annoyance less for the moment.

[endolith]

I'm seeing this just trying to do a very basic VSCode intro tutorial with a single .c file:

https://www.javatpoint.com/how-to-run-a-c-program-in-visual-studio-code

It does actually compile, though, so I guess the error isn't important? Confusing. If I disable the "Makefile" extension, it stops showing the error.

[andreeis]

@endolith, the tutorial is about the C/C++ Extension, not Makefile Tools. There is compilation support with that as well. The error is reported because VSCode detects a makefile somewhere inside the workspace folder but it is not in the root and also not set via "makefile.makefilePath".
Do you have a makefile associated with the .c file you work with? If yes, point to it with "makefile.makefilePath" in .vscode/settings.json.
We will implement a silencer for situations where the user doesn't need to see this error.

[j-marcon]

I support a silencer for situations where there is no makefile in the root.

[rustyx]

Most warning popups in VS Code have a "don't show again" option. Why isn't there such an option in this popup?

[pcj]

+1 this is super annoying. Workaround is to uninstall the extension.

[anaybaid7]

Even though I am connected locally to a server, I still get a deref backtrack to a non existent makefile. any leads on rectification?

[andreeis]

@igenyar, @maciejmatczak, @mvrahden, @endolith , @j-marcon, @rustyx , @pcj , @anaybaid7, we removed the popup notifications regarding makefile and make missing, we left the logging about that unchanged and we are also showing now the "C/C++" tab UI on the left side even when before it was hidden. In there we add now some extra elements about status on make/makefile/build.log: path where we search for them, if not found, you can click the edit pen icon to open settings and change this state via settings like "makefile.makefilePath", "makefile.makePath", "makefile.buildLog" and their "makefile.configurations[]" counterparts.

This will be released with 0.7 next week but if you would like to see how this works earlier you can install one vsix from this link.

go to the Extensions panel on the left
click "..."
run "Install from vsix" from the context menu

Let us know if you encounter any other issues or if you have any other suggestions/recommendations in this area of functionality.

[mcandre]

When will the next version be released?

[andreeis]

@mcandre, testing is almost done (the variable expansion feature took some time to stabilize) and if we don't find anything else blocking we should publish on marketplace on Monday morning. Until then, if you'd like, you can download and install from this vsix to test the last significant feature (variables expansion), the latest UI changes regarding missing pieces like make or makefile.... or to benefit of more bug fixes we made.

More details about what we support for variable expansion:

Besides the highly requested ${workspaceFolder} and ${workspaceRoot} macros that work now from any setting entry-point, we support also:

${userHome}
${env:ENVIRONMENT_VARIABLE}
${config:any_extension_scope.any_setting_id}
${command:any_extension_scope.any_command_name} (this one worked already in launch and tasks json but now they work in settings.json as well). Makefile Tools has the same launch commands we implemented for a while already and you can use any other command that is available. If it returns something useful, we'll expand with the return value.
${configuration} (variable syntax) and ${command:makefile.getConfiguration} (command syntax, accessible in launch tasks json as well) both return what is the current active configuration (what you selected in the left UI, either one of the entries in makefile.configurations from settings.json or "Default")
${buildTarget} and ${command:makefile.getBuildTarget} map to what build target you selected in the UI (or via the command set build target), so it can be "all" or any other individual target from your makefile or expands to empty if you didn't select anything in the quickPick.
If by any chance you need to pass strings with the varexp syntax and you don't want us to expand it use \ to escape it (maybe you pass ${something} via makeArgs or binaryArgs). If that happens in a path, use forward slash for path separator so that we don't confuse it with the escape character.

If we don't recognize the pattern within ${} or something happens while running the referenced command or... we expand to "unknown".
If the first expansion resolves to another ${} varexp syntax we complain in the log that we don't support yet multiple expansion passes and the result is still "unknown". We will support more complex scenarios in future.

Any feedback?

[gcampbell-msft]

@mcandre @igenyar and others, has the most recent release solved your issue? If so, we will close this issue, otherwise we'd love more feedback to be able to better resolve these issues.