[Geany-devel] ANN: Configurable Build Menu Alpha in SVN

[Lex Trotman]

2009/8/16 Thomas Martitz <thomas.martitz at 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 at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>