GitLab

It's used by neochat

This stuff about repo paths used to be less confusing...

In the event that the stash does not apply a "post-build" message is
issued to warn the user. Otherwise there is an in-situ message.

This addresses user feedback I have received on Invent and IRC. In
particular re-fixes #42 and bug 420933, and fixes #49.

All that I do here is to use the existing logic and add "git stash pop"
after the update phase has completed. I've previously tried --autostash
(see !32 and !45) and that had issues of its own. Using this approach
allows us to use rely on git directly without risk of missing a merge
conflict that git sometimes seems to generate with `git pull
--autostash` (see
sdk/kdesrc-build!32 (comment 46926)).

The merge request !61 may still be applicable. I haven't looked long
enough to tell if there's more on it than the --autostash feature which
still causes us problems...  it's possible that there's a more reliable
method than what we're doing though we've already taken pains to
simplify this routine because of the recurring stash failures that we've
seen previously.

BUG:420933

It is only used for libdbusmenu-qt, which isn't built by default any more.

This change should address the immediate breakage that a user had when
using kdesrc-build-setup, choosing no major module groups, and then
using kdesrc-build to eventually build bluez-qt.

In that case, bluez-qt had an 'options' block in
kf5-frameworks-build-include to address the error he'd experienced,
however since kdesrc-build-setup didn't generate a include to that file,
the options weren't picked up either. kdesrc-build later found the
module via include-dependencies and built it anyways.

To fix this, break out "always-set" options into a dedicated file
(kf5-common-options-build-include) and include that from
kdesrc-build-setup-generated files always.

I moved these from kf5-frameworks-build-include so I added an include
from that file back to kf5-common-options-build-include for backwards
compatibility for existing users. This relies on duplicate options
blocks continuing to work (similar to C++'s One Definition Rule) so I've
documented that in the code for now.

CCBUG:426219

My hope is to make it easier for new users to understand how to add
module groups if they are desired later, since there has previously been
no generated note or warning in the generated kdesrc-buildrc if the user
chose no major groups.

In this case we had a user who, even though they didn't select any
module groups, still had kdesrc-build trying to build bluez-qt due to
include-dependencies being set to 'true' (the default). However bluez-qt
needs a CMake option to be passed to build with kdesrc-build; this
option isn't set unless the kf5-frameworks-build-include file is read
in.

That fix will happen in a separate commit, this should hopefully make it
easier to read through the generated kdesrc-buildrc in any case.

CCBUG:426219

This seems needed for some KF5 modules (especially using QtWayland) and
is where I expect most Qt5 bugfixes to land while everyone is working on
Qt6/KF6.

They are required for kaidan and qrca.

The sample xsession/environment setup shell script has to figure how
where CMake is going to install the libraries that kdesrc-build builds,
so that it may setup the proper override paths in the environment.

These library names are a cornucopia of names across various Linux
distros. Some systems have /usr/lib, others use /usr/lib64, some use
both, some use /usr/lib and /usr/lib32, and still others use a combo of
all three, with /usr/lib having the "right" libraries and one of the
other specific paths being a symlink back to /usr/lib if appropriate.

In this latter situation our script guesses the wrong library name, with
predicable failures from there. This breaks Arch Linux if users don't
know to fix the session driver that kdesrc-build installs.

The fix here is simple, we only treat /usr/lib64 as the authoritative
library path if it isn't a symlink elsewhere. Otherwise we use /usr/lib
as normal and assume that CMake itself will also create a path ending in
/lib (and not /lib64 or /lib32).

Fixes #52, and my thanks to Vlad for the detailed bug report, steps to
reproduce, isolating the cause and testing the fix.

This was all replaced with Getopt::Long years ago but I missed this
during that refactoring.

For now it's only commented out but the module hasn't changed in many
years so there's really no need for kdesrc-build to have to build it. It
should be installed from -devel packages instead as we do with other
distro dependencies.

I've commented it out for now as an indicator this was deliberate, but
I've taken the liberty of updating the distros in ksb::FirstRun as
appears to be appropriate. After a few weeks we can remove the commented
section as dead code.

See issue #53.

eg. if we're cloning libdbusmenu-qt into ~/kde/src/libdbusmenu-qt, the
bzr command should be run from ~/kde/src, not
~/kde/src/RANDOM_OTHER_MODULE as apparently is already happening.

I believe this fixes #53, if it doesn't please reopen. My distro doesn't
package bzr anymore so I will remove our usage in a separate commit but
will maintain Updater/Bzr.pm for at least a few more months with prior
warning of deprecation. But I will need help testing :)

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

Replace repository URLs for taglib, poppler, qtspeech and telepathy-qt
to use HTTPS instead of unencrypted git:// URLs.

Fixes #50

kirigami is a framework now, doesn't need its own definition

Closes !55, which has diverged from master since I've been able to
approve it.

 - Set $shellName as 'undefined' if SHELL env variable is undefined
 - _setupRcFile: Change 'Add...' to 'Added...' in the messages
 - _setupBaseConfiguration: Fix messages and adjust control flow.

 - Respect ZDOTDIR env variable when updating shell rc.
 - Prompt user to ask for updating shell rc-file.
 - Make messages more detailed.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

It is annoying to be maintaining kdesrc-build-setup and --initial-setup
but combining those two can be a subsequent refactoring.

This adds a separate num-cores-low-mem to address the qtwebengine case
and makes both num-cores and num-cores-low-mem into an option generated
during initial setup, and only used by the default config (rather than
any part of the kdesrc-build internals directly).

There is a fallback reference in the code in case there is a usage of
the default configuration file sections (e.g. qt5-build-include) but
this is set conservatively (4 cores, 2 cores during low-mem).

At this point it's almost "just" a configuration convention with a bit
of code in the setup wizard so perhaps it's best not to touch the rest
of the code/docs at all, but I'm happy with where this is at.

I've tested --initial-setup in a Docker container (Fedora 29 with perl
manually installed first) and tested kdesrc-build-setup separately.

I was off by a few days but 20.06 feels better than 20.07, so here we
go anyways. It's cosmetic only at this point anyways.

This change introduces a "num-cpus" option that is inherently present in
the build context.

This permits config file reading code to refer to this option (due to an
existing kdesrc-build feature). So I also update the various available
methods of generating a default configuration to use this option instead
of hardcoding a -j value for make-options (or leaving it blank).

This should provide maximum performance for most users (who aren't using
or can't use the existing Ninja support, anyways), as long as they are
able to start from a generated configuration.

Users with existing configuration files would need to regenerate it or
edit it to add "make-options -j ${num-cpus}" (including separately to
their Qt5 options if applicable, as global options are ignored for
non-KDE modules).

See issue #39.

With the advent of Qt6 development, the pace of Qt5 has slowed enough
that we can now rely on distribution packages being available and up to
date for Plasma development.

Since Qt5 remains a significant pain point for kdesrc-build users, we
shouldn't inflict this requirement by default for new users.

gpgme 1.13.1 (released in 2019) works fine.

Previously we incurred additional network I/O due to git pull (for reasons to do with a bug in certain git versions).
However, with the new stash logic we can assume a clean checkout and so an update should always be a simple fast-forward to the remote HEAD.