Post dry-run cleanup script

[CityAplons]

Greetings,

Is it possible to run a custom bash command to clear the workspace after dry-run? I'm currently working with NuttX code-base and like how this plugin works! However, after each dry-run I have a lot of auto-generated files in the root of project workspace.

Currently, I am manually using an alias with the following string: rm -r *.dds *.ddc *.ddx *.ddp *.ddh Make.dep It will be nice to hook it after a plugin doing a dry-run and, probably, will be helpful for other users.

Best regards, N.M

[bobbrow]

We don't currently have such a feature in the extension. I'm surprised the dry run causes files to be created. When you build do those same files get generated too?

[CityAplons]

Thank you for a response!

Hmm... never saw them before with or without configured project, except Make.dep. As I understand, they are recursively generated by a nuttx toolchain dependency generator (definition, generator source), and purged when a Make.dep file had been successfully generated.

I've tried dry-running manually and, yes, there is a lot of mkdep calls per each directory. However, Make.dep files were not generated, neither any of *.ddX files.

I made some experiments and catch the stage, when files are actually starts to flooding the root of a project:

[andreeis]

@CityAplons, we can definitely implement some post configure script to run anything a user wants at the end of configure (same as we do now for preconfigure, before). I am surprised about the "parsing for launch targets" stage. I don't know how that can generate any files because (in theory) we only parse the output of a finished dry-run at that point. You can try something to confirm: obtain in a terminal a full clean build log of your project and point "makefile.buildLog" towards it and reload the project. This will skip dry-run completely and will also run the stage "parsing for...". Let's see, do you see the new files being created now? If not, then this can be your workaround to not worry about the many leftover files. Only one disadvantage for this approach: you need to recreate the full clean build log with every new source file or relevant compiler switch change, anything can may impact C/C++ IntelliSense (which normally would be caught by a live invocation of a dry-run).

[CityAplons]

@andreeis, thank you for the response! I have checked the proposed solution, with skipped dry-run and parsing stages. Generated dep files are not being created at all. However, because of the Kconfig frontends use, this solution is practically unusable. Any configuration change will lead to an outdated build log. I have an idea of how to automate the re-creation of a build log, however, making each time build with distclean will give me a lot of free time :)

Currently, I made a task with a given bash line, and periodically clean my workspace on purpose.

P.S.: attached logs files, if needed for a context.

[andreeis]

@CityAplons, glad that you are unblocked with this solution. I am reopening the work item though because we can implement the post configure hook for anything our users may want to run. Triaging it for post 0.7.

[LaurentLouf]

Post configure hook would be very great ! I have a script that parses the content of the files generated during the dry-run to overwrite the C/C++ properties file, and that would be nice to be able to launch it automatically after a configure

[andreeis]

@LaurentLouf, just curious: what are you parsing for? Are you duplicating the extension functionality? If there is anything missing or wrong we would like to improve in our feature set. A few details on what your script is doing and why you need it would help us possibly create and triage new work items for the future.

[LaurentLouf]

@andreeis I'm parsing for include paths and compilation variables. I know it's supposed to work out of the box with the extension, but I never managed to get something working properly. My script is actually here if you want to have a look https://github.com/LaurentLouf/makefile-info-extract-for-vscode/blob/main/vscode_configuration_provider.py

[andreeis]

@LaurentLouf, I'll take a look at your script. In the meantime, if it happens that your code base is public, you can share it with us. Maybe we can help you set it up properly and you won't need the script at all. We were able to help numerous developers with various steps in their process. Many times there weren't bugs in the extension :). Also you can archive and send email to makefiletools@microsoft.com for more sensitive code bases.

[LaurentLouf]

@andreeis : the configure and the build step are working, so for me the configuration is OK. And I tried by making this extension as the configuration provider. So on my user point of view, there is no sign indicating that it doesn't work as intended, except that it doesn't. There needs to be a better error handling if it can silently fail like that

[andreeis]

@LaurentLouf, please clarify, the extension never works for you or only sometimes? This looks like silent failing but in reality is missing or limited information and we never know if the information we get (from the output of the dry-run we invoke behind the scenes) is complete is not. If we detect that "make" failed we report the non successful error code. But if the "make --dry-run " (followed by any other args you define via "makefile.configurations") succeeded but your makefiles use silencing directives or uses tools that don't report anything useful for us, there is no way we know data is missing. It would help if we see your project or you send us some logs, like: Set "makefile.loggingLevel": "Debug", "makefile.extensionOutputFolder": "./OutputFolder", "makefile.extensionLog": "extension.log" in your ".vscode/settings.json" Reload your project, let it configure.... then share with us the following files from the "OutputFolder" directory: "dryrun.log" and "extension.log". Then point me to a file name .c/.cpp, full path, that has IntelliSense not working properly (red squiggle on an #include or a #define that's not expanded properly or...). I am sure we can make the extension work reliably for you all the time.

[gcampbell-msft]

@CityAplons This feature is now available in pre-release! Feel free to try it out and create new issues if there are problems. Thank you!