The message gets a bit more annoying as the number of warnings increases. I
store the number of warnings as well so that future versions can give a really
prominent message if new warnings are introduced since the last build.
Right now this only makes some of the code intent a bit clearer (saying "was
successful" instead of checking against non-bool values). But this would also
be useful for tracking stats on compile warnings.
There is code to avoid using the TTY code that updates the status of the
build in the current line. This code prevents using the fancy TTY stuff
if progress output is not supported, but doesn't actually ever output
the end result of the build (success or failure), which wasn't the
intent.
In the other situations we don't want to clutter the line output with a
redundant status. Instead of duplicating the "progress output
supported" check later to output the status (or not), I just took out
the check for whether progress output is supported entirely, since the
progress callback can work even with build systems w/out support.
BUG:391396
FIXED-IN:18.04
Many work (e.g. qtxmlpatterns) work just fine with qmake using srcdir !=
builddir, but most do not and instead assume a srcdir == builddir.
This is difficult for kdesrc-build (we generally assume we can delete
everything under the build directory) so reintroduce the old builddir
hack that symlinks all the files in the srcdir under the builddir.
To avoid needlessly throwing symlinks around for the existing
QMake-using modules (which apparently all already work), this only
applies to modules with a repository under qt.io.
Note that qtbase should be handled by a separate build system (still
called "Qt4.pm" and doesn't fall under this hack.
Now we describe up-to-date module progress (if multiple modules are
being built) and consolidate muliple lines of information into just a
couple (for build and install).
Should be a bit faster, but major goal here was to decouple the progress
output from the details of what we're outputting to. Functionality is
still the same (except that ninja progress output now works too) but now
it's that much easier to permit additional means of progress updates in
the future (e.g. a GUI, web server, even a Plasmoid).
I had made some build-system related options not automatically apply to
modules with customized build systems (e.g. Qt, CMake, "custom"). But
this seems like the kind of option we'd want to have in common, as noted
in a bug report to me by Andre Wöbbeking, so make make-install-prefix
apply to all build systems by default if it's a global option.
This can, of course, still be overridden for individual modules or
module-sets.
This is a first-step hack to have non-default build systems ignore
global options which are related to the build system in use (e.g.
compile or make flags, install/uninstall options, etc.).
This should fix bug 331654 (now that I understand it better) and improve
the situation for bug 332789 (which would be the long-term fix when
implemented).
BUG:331654
CCBUG:332789
FIXED-IN:1.16
This patch does three things:
1-Adds --install-only for the sake of consistency
2-Adds --install into the usage
3-Makes the CMake (KDE4) build system use make install/fast.
make install/fast only performs the installation of the files
thus avoiding a double compilation.
REVIEW: 116589
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).
Michael Pyne
David Faure
Àlex Fiestas