> When it comes to actually execute a command I planned to use > build_set_menu_item(), build_activate_menu_item() and to introduce a new > build source called GEANY_BCS_PLUGIN. But just adding a new build source is > not doing the job. I guess build_activate_menu_item() is simply ignoring a > new value.
Yeah, you have to program everything that gets commands to know about it, the overloading order isn't straightforward, so its explicitly programmed, so a new source needs to be programmed in too, see for example `get_next_build_cmd()`. You also need to allocate the command array somewhere. > Also, the workbench plugin maintains several projects and that would mean to > re-write the commands each time by calling build_activate_menu_item(). And > the functions doesn't seem to free old values by itself. I presume you mean `build_set_menu_item()` and there the `SETPTR()` macro does the free. > The first parameter given should tell if the command output goes to the > "Compiler" message window. An alternative value would be > BUILD_TARGET_NEW_TERMINAL which means start a terminal and run the command in > it. This seems to be what the groups GEANY_GBG_FT /GEANY_GBG_NON_FT and > GEANY_GBG_EXEC do today. Well those groups do rather more than that, especially execute which makes the script and then runs the command without monitoring its stdout and stderr. > The API call should work in a Fire&Forget manner: parameters command and > workingdir should be copied (if necessary). Then run the command as described > above and once finished simply forget about command and workingdir. It can't be fire&forget since it has to monitor the command and restore the menu sensitivity when it finishes. If you want fire and forget maybe you would be best to spawn the command yourself, though that would mean doing your own replacements. I'm not sure where they are used, but the build info structure stores the group and index while the command is running, so a command without those may be difficult to integrate. When the build command system was upgraded to the current cascading overload system, one of the devs objected to it and did not want to make it visible to plugins because he wanted to change it. So the doxygen comments were disabled by adding a space between the `**`. That dev is now inactive and, over time, because people have needed access to the build system from plugins, some parts have been made visible in a somewhat ad-hoc manner. You can still see some disabled doxygen comments in build.h and build.c. Probably the whole visibility of the build API could be revisited, for example if `GeanyBuildCommand` was available to plugins then they could manage the plugin source array themselves and so could set its size themselves. The Geany arrays are set at startup only from values in the config, and that wouldn't be terribly convenient to plugins. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1897#issuecomment-405125486
