_verifyRefPresent was also broken for tag-based checkouts. Since this
already uses determinePreferredCheckoutSource, which already used
refs/tags/ for tags, this code also doubled-up on tag names.
This whole code path would be a great candidate for that test suite
under t/ if I can ever get it polished up one day :(
To avoid commit spam, I've tested this on my own Qt module directories
by deleting them and forcing them to be checked-out with tags.
Turns out the original code was doubly-broken, since
determinePreferredCheckoutSource was already adding refs/tags/ to
returned git tags.
Rather than possibly breaking other users of that function by removing
it there, instead strip off refs/tags/ during clone if present.
git-clone doesn't like this value as an option to --branch/-b. Instead
just leave it as a plain tag name and hope it doesn't conflict with any
branch names.
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
The warning here complains about conditions which are already pretty
much fixed from outside of the kdesrc-build user population anyways.
It's still something notable so instead of removing completely I
downgrade it to a debugging message.
BUG:388657
FIXED-IN:18.02
The move to JSON storage of persistent opts break first-time users,
since the refactored code never actually gets around to setting a
persistent_options key in the build context object.
This seemed to work previously with Data::Dumper, but JSON::PP is not
happy with being asked to serialize an undef. On the other hand I had
always thought that sub setPersistentOption would have 'autovivified'
the needed hash table, and the reporter's build process should have
resulted in many calls to setPersistentOption over the build.
BUG:388180
FIXED-IN:18.01
My attempt to make the KDEProjectReader's check for YAML be a runtime check was
thwarted because I had separately used a "use KDEProjectReader" elsewhere,
which Perl ensures happens at compile time.
Instead make the check part of the constructor so that the package can at least
compile without throwing an error.
Perl seems to have settled on the 'parent' module instead of manually defining
variables that tell the interpreter which packages to fall back to. Some
classes now use parent, some still use the old way.
Migrate everything over to be consistent.
YAML is not an appropriate fallback from what I can glean of Perl
community discussions. YAML::XS is preferred, or YAML::Syck. If I can
get repo-metadata to conform to a stricter YAML subset then YAML::Tiny
would work too.
CCBUG:388109
This is needed to try to perform filtering of the module list based on
which git branches are available, which we could do easily when using
kde_projects.xml.
Without that data, we effectively have to wait until the module list is
already made and about to git update a module before we can tell if the
branch will be there. By that time it's too late to have filtered the
module list, so we have to determine whether this should be a hard error
or not later in execution.
To make that choice, we essentially need to know whether the module is
being built because it was specifically asked for or whether it was
brought in as part of a larger module set (and therefore can be ignored
if the git branch is missing).
This adds tracing for the config file to supplement existing tracing of
cmdline selectors.
Maintains a user-friendly improvement from a few years back to make it
easier to use module-sets to grab a wide set of modules without having
to disable individual modules that weren't present at that time.
Qt5 modules built from git rely on git information being available to
generate private headers and the like, so don't strip out the .git
directly when using builddir hack.
Likewise, using the "-r" flag to force a full recursive search for .pro
files causes qmake to error out on some modules where the .pro isn't
meant to be built as part of the module build (e.g. examples).
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.
The log directories are stored in a central directory in the
BuildContext so that we know which ones we're supposed to reuse. But
this only happens on first use. If this first use happens during an
async build it won't be properly persisted, so each succeeding build
will think it's the first one to need a log directory.
This can happen for modules that use a log directory different from the
global directory.
This "last-build-rev" persistent option is probably more appropriate for
Module.pm anyways, since there is already a similar "last-install-rev"
check in there.
This should be unnecessary for new clones (git does have an option to
not pull tags however). More importantly it's actually broken (we need
to cd into the newly cloned directory if we want to do it anyways).
The qtdir setting took on much less importance with Qt 5. We've never
officially supported building Qt 5 with kdesrc-build, and qmake and
cmake both use qmake or similar Qt-provided config information to find
Qt, rather than using the unsupported QTDIR environment variable.
As a result, default the value to an empty string (interpreted as use of
system Qt) and stop adding it automatically to the environment variables
defined during the build. If set, it will continue to be used for now.
This also helps the environment setup driver detect when it should look
for the system Qt5 qmake.
Noticed that some of the kf5-*-build-include files use multiple
ignore-modules declarations for a single module set. I like this, it
allows for commenting why the modules are being ignored. But it
shouldn't have worked before. Now it does.
I thought KF5 had removed /apps/ from the DATA_INSTALL_DIR, and so
adjusted the CMakeLists.txt install to match when it turned out my
module search paths were wrong. Turns out /apps/ is used, so put that
path and adjust module search paths instead.
This installs needed KDE-related environment settings without going so
far as to install .xsession support. For that, see
install-session-driver, whose documentation has been fixed to make clear
it's not a default.
The kde-env-user stuff is probably extraneous, users who will go through and
tweak the installed kde-env-master.sh script should be skilled enough to
already have their own .bashrc (or equivalent) and be able to setup their own
env vars prior to sourcing kde-env-master.sh
This also ports some of the Qt4/KDE4 stuff to Qt5/KF5, removes now-unnecessary
environment variable settings, etc.
This installs needed KDE-related environment settings without going so
far as to install .xsession support. For that, see
install-session-driver, whose documentation has been fixed to make clear
it's not a default.
It turns out that there is a code path where ksb::Module objects in the
process of being created do not have ModuleResolver::_applyOptions()
called on them to ensure that deferred options (from "options" blocks in
the config file) as applied if necessary.
This affected modules like libdbusmenu-qt, which if processed as part of
generating the build list from the config file would *NOT* have
_applyOptions() called (because expandModuleSets only ran this on
ksb::ModuleSets being expanded, and the resolveSingleSelector call that
otherwise would have run applyOptions is only called when modules are
passed as cmdline "selectors").
Fix by pushing _applyOptions to be called for all modules processed
through expandModuleSets (which despite the name gets a cut at every
module in the module list), and removing applyOptions from
resolveSingleSelector since it's redundant now.
BUG:382172
FIXED-IN:17.08
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.
Michael Pyne