GitLab

This should prevent the new-to-1.14 setup script from becoming the next
Debian lintian warning.

asciidoc was a nice start, but modifying the generated XML is not too
bad (and must be done to comply with KDE documentation guidelines
anyways).

So, remove the asciidoc and instead generate man pages from DocBook XML.

I've taken the liberty of using the more specific content tags but the
overall content should be approximately the same.

I probably should have done this a long time ago, but now kdesrc-build
has a man page (mostly to get rid of the 1 Debian lintian hit I saw for
1.13)

I haven't tied it into CMake yet because I'm tired, but it requires
asciidoc and the short story is:

$ asciidoc -d manpage -b docbook kdesrc-build.1.txt
$ xsltproc --nonet /usr/share/asciidoc/docbook-xsl/manpage.xsl
kdesrc-build.1.xml

Of course finding that damn XSL from CMake will be the problem in the
future but I can figure that out tomorrow if no other kind soul does
that for me.

Raphael Kubo da Costa noticed that his set-env in module-sets were no
longer working in master.

Turns out a simplification of the setOption method to allow accepting
more than one option did not properly handle the set-env option if that
option had already been processed. (kdesrc-build has to convert set-env
read from the rc file into a hash instead of just storing the value to
allow for duplicate set-env entries).

This is fixed by ensuring that if that processing step has apparently
already been completed, we don't try doing it again.

GIT_SILENT

The Coverity plugin interface was removed awhile ago and I've seen no
anguished screams since. I can only assume Coverity no longer uses
kdesrc-build for KDE code scanning (I am uncertain whether Coverity
still checks our code base at all).

As recommended by Pino Toscano.

I was also half-tempted to just force-exec the setup script if it's
available and there's no config, but there are some scenarios where it
might make sense to just download kdesrc-build and kick off a very quick
build from there (especially with the +xml-module syntax on the command
line).

Ask requested by dfaure, belatedly add a --no-tests option to disable
enabling tests *at CMake* time for that run. Delayed since I was going
to implement it after refactoring out each step into independent phases
but I haven't quite made it that far yet.

BUG:265275
FIXED-IN:1.14

Really this was mostly an excuse to document the new "include" feature.

The option can actually still be passed since kdesrc-build accepts
command-line options matching known global option names, but since
we default to removing old log directories there's no reason to add 40
different ways to enable this.

kdesrc-build uses multiple processes for its operation (even without
async mode), the way Perl works means its END {} handlers get called
even for the children.

The real way you'd normally see this is by doing ^C at the terminal, the
signal handler would manually run the exit routines and then the END {}
block would run the same routines.

If a user generates a configuration file that kdesrc-build won't pick up
by default, then show a message after the setup script runs warning them
about that and letting them know what they have to do.

Now it supports:
* Backup existing configuration and overwrite
* Custom configuration filename.
* It even automatically falls back to a tempfile if backup fails.

Ever since kde-projects XML support was added you could (in theory) use
the syntax +modulename on the command line to force kdesrc-build to
interpret that module as an XML module.

Later a filter was added to avoid building modules on typos, which also
trapped all +modules.

Now if you use +module on the command line kdesrc-build will keep
processing it, and catch misspellings later or build the whole module if
it's actually defined in kde_projects.xml.

kdegraphics actually needs it as of this writing since it is marked as
inactive in projects.kde.org. Even if it is made active, kdegraphics's
repo should not be built in conjunction with its logical children's
repos.

qt-kde wasn't updated in aeons so sysadmin team moved it to be a
straight mirror of Nokia's gitorious Qt repo. Let's adjust to match.

As suggested by dfaure and at least one other person whose name escapes
me now, with all the modules available in git.kde.org it makes sense for
their on-disk layout to match the hierarchical organization given in
projects.kde.org, so kdesrc-build now does that.

If there's a big hub-bub about this I can make it optional, however I
think it should hopefully not be too hard to adjust to. A later commit
will add auto-migration of old source/build dirs because I love you all.

CCMAIL:dfaure@kde.org

Modules like kdegraphics are both the ancestor of a group of logical
child modules, and repos in their own right. kdegraphics is marked as
non-active since it's repo just exists to allow for building the
subprojects, but that means kdesrc-build won't build it.

So, allow for specifying modules *under* a given module. This allows for
a syntax as follows to work:

module-set kdegraphics-set
    repository kde-projects
    use-modules kdegraphics/libs kdegraphics/*
end module-set

(The kdegraphics/libs forces those modules to be added first. They will
not be readded by the later kdegraphics/*)