Basically, modules which are updated by default but not actually built
(e.g. due to using the manual-build option) are never mentioned in the
kdesrc-build output in the default async mode of operation.
This required a bit of refactoring of the IPC code to fix, since the
underlying cause is that the output during async mode is driven by the
needs of the build thread, which would request updates from the monitor
thread on a per-module basis. But the build thread never inquired about
modules only being updated, so any such modules were never mentioned on
the command line.
Once I figure out a "preferred" solution for this use case I'll probably
convert to that, until then no reason to pollute with warnings.
I've run a search for other uses of given/when and didn't see any.
As opposed to reading /all/ output for a given module and only
displaying it immediately before the build phase starts. This makes it
very disconcerting to track git-clone progress...
Though this only works for Git modules, it should at least fix the
annoying "OMG YOUR REPO MOVED" warnings that never get fixed when in
async mode (which is the default).
Previously you simply never saw the warning due to the now-fixed output
squelching, now we need to fix this for good as well.
The build thread owns the TTY in the current setup. To keep the update
and build processess from fighting over the TTY when in async mode,
we've been simply squelching the update output up to this point, except
for errors.
This is not really the best idea as it can leave out kind of important
details. With this change we configure the logging subsystem to forward
its messages that it would ordinarily print out to instead go over an
IPC channel.
The IPC channel knows which module is currently being operated on, tags
the message, and forwards it over to destination proc's IPC handler,
which extracts it and holds onto the message until that proc reaches the
same module.
Once the receiver proc is processing the module, those messages are all
output at once and then normal processing resumes.
In case some messages are never read out this way (e.g. a module is
updated but never built) we have a message scavenger right after the
build is done to give those messages as well.
This commit removes the 'megaclass' code that IPC::Pipe has become to
support two different dataflow paths in a single class.
Instead, we use up to 2 different IPC objects in async mode to give the
dataflow needed.
Splitting this up required moving the message boundary detection code
back to IPC::Pipe. It is now expected that a given IPC subclass is able
to pass messages with message boundaries intact, and to block while
waiting for messages if concurrency is supported. IPC::Null already
maintains message boundaries and doesn't support concurrency.
Previously IPC and IPC::Pipe cooperated to perform message boundary
detection, by inserting and removing '\n' characters. This was always
kind of a hack. Now we simply pass the message length across the pipe
followed by the message, and ignore the idea completely in IPC.
The impetus for all of this had been to improve performance, but
unfortunately that hasn't happened here, although it's still a positive
change from the code simplicity front.
This can be used as a run-time check later to ensure that kdesrc-build
finds compatible versions of its component modules (though that isn't
done yet).
Easy enough, seemed to work the first time. But I had to be careful to
remember to re-insert 'use IPC;' package declarations in each individual
module actually using these constants. It should be possible to remove
the ksb::IPC stuff by exporting the constants from the IPC.pm using
Exporter, but I'm not doing that at this point.
Michael Pyne
David Faure