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.
Albert Astals Cid fixed dependency-data, Ben Cooksley fixed the module
layout of kde/kde-baseapps* in kde-projects, now to fix the recommended
build order in the samples provided.
The relevant KDE bug for the module moves is Bug 316629.
Should be permanently fixed this time by doing what I should have done
in the first place and making the "needs metadata?" predicate a separate
return value.
Should hopefully be pretty much what it says on the tin. Stop either
right before or right after the given module. (GUI flag since this
involves documentation changes to the Handbook and man page).
BUG:315251
FIXED-IN:1.16
GUI:
applyModuleFilters() would quite happily filter out the metadata module
automatically added to a kde-projects build.
Without the metadata module, later code paths wouldn't know that they
should perform dependency resolution or handle build-script-ignore (as
all 'proj' modules have been expanded to 'git' modules by that point).
BUG:315394
FIXED-IN:1.16
Really I should probably factor out the various 'proj'-creating routines
into a single point of awesome but for now let's just use the old
behavior as a backup in case users give command-line modules...
Commit aa1e4b9542 introduced changes to
how "proj" modules are first parsed (simply keeping the last path
component as entered by the user as the module name).
The unintended side-effect of this is that the user doesn't always have
to enter path ending in an actual repo. E.g. extragear/utils is not a
repo, it would get reduced to "utils", and later KDEXMLReader would
effectively look for all repos matching "*/utils/*".
For more fun, do what I did and try "kdegraphics/libs" => "libs" =>
"*/libs/*"...
Anyways, the fix here is to use the normalized module name as the module
name, but use the full user input for the XML search.
CCBUG:299415
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.
In synchronous mode it was impossible to get the build subroutine to
attempt to build a module which had no source update, as the updater
code would filter out its build phase *in addition* to marking it as
up-to-date.
This never broke the async code as filtering out the build phase was
always unimplemented (which is what led to a specific IPC type for "code
up-to-date" in the first place).
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.
It's kind of annoying to be unable to build all modules in a certain
kde-projects module grouping, *except* for some certain chosen ones.
Now you can: You can add the ignore-modules option in your module-sets
using kde-projects repository.
It accepts a space-separated list of module names (either kdefoo or
kde/module/kdefoo style) to ignore.
Although the intention is to only filter out matching modules in *that*
module-set, it would actually perform the filtering even if you
accidentally put it in the wrong module set due to a fluke of the
implementation (I recommend not relying on this, however).
The documentation has also been updated, including an example of the
usage.
For whatever dumb reason I coded the "ignored kde-projects modules"
handling (kde-build-metadata/build-script-ignore) by having the code
that reads in the list of ignored modules go and immediately update the
build context.
For obvious reasons this only works when the update is actually
performed, which means ignore information wasn't used in pretend mode.
We fix this by moving the build context update to the rest of the
metadata handling.
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.
Michael Pyne
Montel Laurent
l10n daemon script
David Faure
Burkhard Lück
Raphael Kubo da Costa
Yuri Chornoivan