2009/8/16 Thomas Martitz thomas.martitz@student.htw-berlin.de:
Lex Trotman schrieb:
Hi Thomas,
Good to hear that there are no major problems.
I can see that you may want to kill a long build that you started by accident or when you realise you forgot to do something first. I've done that more than once ;-)
In Geany execute changes to stop while running, but build doesn't.
The difference is because they are run in different ways, execute runs in a terminal (either external or VTE) but build commands are run directly so that no terminal window pops up and so that the output can be captured for parsing for errors. Due to problems on windows, builds have to be run synchronously on windows, ie the whole of Geany freezes while the build runs (why? I don't understand exactly, maybe Enrico can explain it). That means that cancelling a windows build can't be done from Geany anyway.
Whilst Linux builds are still asynchronous only one is allowed at a time so that output isn't mixed up in the error parser. So all build commands are set insensitive until completion. To have one menu item still enabled and to have it change to stop is going to be quite a bit of fiddling unless it is always a fixed menu item or a toolbar button.
Seeing that the Run commands don't gray out too, I think adding a cancel button which doesn't gray out is going to be doable without a lot of fiddling.
But as a general action I would be worried about killing a build anyway.
Geany only knows about the parent process, the top level make, not any children that make forked to process subdirectories, or because -j was used, and they won't get killed (they migrate to be children of init). The overall impact is not well defined, but killing a top level make may leave most of the build still running. Now setting the build menu items sensitive and so enabling another build is risky.
And the results of builders other than make is even less well defined.
The Rockbox build system (see [1]) has a way to kill builds (even those which are started with -jX) using this snippet of perl code. Note that kill here is a perl function, which does IIUC killing the childs for us (it kills the process groups if the signal parameter is negative). I don't know if it helps us though. Could one try call the perl function from within geany with a crude hack/magic?
Um no, that would require Geany to have a dependency on Perl, and I doubt that such a requirement would be acceptable to the general Geany community.
I havn't written perl for a while but this seems to depend on the global builds variable, whats that got in it and where was it set??
sub killchild { my ($id) = @_;
return if (not defined $builds{$id});
my $pipe = $builds{$id}{pipe}; $read_set->remove($pipe);
$busy -= $builds{$id}{cores};
my $pid = $builds{$id}{pid}; kill -9, $pid; tprint "Killed build $id\n"; waitpid $pid, 0;
my $dir = "$cwd/build-$pid"; if (-d $dir) { tprint "Removing $dir\n"; rmtree $dir; }
delete $builds{$id}; }
I actually got interested in adding the configurability to Geany build system when an organisation I was consulting to was using Geany but running builds on a server farm with several versions of Linux, AIX, HP-UX, Solaris and several windows versions. And different pieces of software from many different sources used many different build systems, hence the need for configurability.
Of course such remote jobs won't be touched by any signals.
According to the reference you provided on Rockbox it does remote builds by copying data from SVN and then copying the results back. So a remote build can be cancelled by its special server on the remote system (I guess thats where the perl snippet came from) and thrown away and no corruption is possible, but our system used shared sources for all machines and locks to control multiple build interactions. Killing things could leave locks about and block builds until someone removed them manually. Worse some pieces of software could corrupt the build tree if cancelled (sure they were lousy build scripts, but we used software from lots of places and didn't want to touch such things unless absolutely required)
While such a system is unusual, it made me very aware that the area of child processes in Unix (ignoring windows) is very flexible and not always fully standardised ( eg Linux pre 2.6 is not exactly POSIX). Remember even if it doesn't run something remote, a build could easily spawn background processes that can't be killed from the parent because they are not part of the same process group, so if the perl function only kills the group it still won't get them.
And your killall only works because you know that you are the only make running on your machine, it would be considered impolite if you were to kill someone else's make by accident :-)
Its an area where caution is required to avoid real problems. If you have a solution that works for you, great!! Configure it for yourself, but it can't be offered as a general solution unless safe (oh, and useful ;-)
I think we need to consider this a bit more first to find a safe general solution.
In the interim why don't you configure an extra execute command to run the "killall -9 make". It can then run asynchronously whilst the build is running.
Because my run (and build) command list is full ;)
I keep running out too :-D
With the build-system branch the hidden preference number_exec_menu_items can be set to increase the number of execute commands, see the build-system version of geany.html preferences file format section.
Filetype and non-filetype numbers can also be increased so you can add make commands too (you can't decrease them). Close and re-open Geany before they take effect.
Cheers Lex
Best regards.
[1] http://daniel.haxx.se/blog/2009/07/05/concepts-of-a-new-distributed-build/ _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel