1. 24 Jan, 2021 1 commit
  2. 21 Jan, 2021 1 commit
  3. 12 Jan, 2021 1 commit
  4. 05 Jan, 2021 1 commit
  5. 28 Dec, 2020 1 commit
  6. 23 Dec, 2020 2 commits
  7. 21 Dec, 2020 1 commit
  8. 12 Dec, 2020 1 commit
  9. 07 Dec, 2020 1 commit
  10. 03 Dec, 2020 2 commits
  11. 30 Nov, 2020 1 commit
  12. 28 Nov, 2020 1 commit
    • Johan Ouwerkerk's avatar
      feat!: 'support' git submodules when cloning a repository · b971771c
      Johan Ouwerkerk authored
      This is the bare minimum dumbest possible thing that could possibly work.
      Nota Bene: this feature is not robust against 'abuse' by multiple modules trying to build the 'same' bundled libraries and then install the result into the configured kdedir.
      Such modules will end up overwriting each other's artifacts and you get to keep the pieces.
  13. 27 Nov, 2020 2 commits
    • Johan Ouwerkerk's avatar
      fix: better error messages in case the local Perl setup is too barebones for... · 2ea73c2c
      Johan Ouwerkerk authored
      fix: better error messages in case the local Perl setup is too barebones for kdesrc-build to work with
      Previously no matter what the user did, if their Perl environment was too minimal they would get an ugly error message from the compilation phase (BEGIIN).
      This was caused by explicit `use` references to various 'standard' Perl modules, such as e.g.: File::Find.
      The same issue also prevented the logic for 'nicer' error messages which is intended for those very same conditions from working properly.
      By moving code around a bit, kdesrc-build will still not 'work' on such minimal Perl environments but at least the user will get better errors.
      Issues: #56
    • Johan Ouwerkerk's avatar
      fix: do not error out on missing Perl modules until actually necessary · 3f37bc1e
      Johan Ouwerkerk authored
      Previously kdesrc-build would error out even before commandline options parsing if certain Perl modules are missing.
      This behaviour is both confusing, unhelpful and incorrect depending on the situation because kdesrc-build would never get to the commandline options parsing stage:
       - For invalid commandline options, kdesrc-build would show an 'unexpected' error message instead of pointing out the invalid commandline option
       - For simple options like  --help and --version an unexpected error would appear, even though those options could still work
      Issues: #56
  14. 26 Nov, 2020 1 commit
  15. 24 Nov, 2020 1 commit
  16. 20 Nov, 2020 1 commit
  17. 19 Nov, 2020 1 commit
  18. 08 Nov, 2020 1 commit
  19. 07 Nov, 2020 1 commit
  20. 31 Oct, 2020 1 commit
  21. 25 Oct, 2020 1 commit
  22. 24 Oct, 2020 1 commit
  23. 11 Oct, 2020 2 commits
    • Michael Pyne's avatar
      git: Automatically reapply stashed changes if possible. · c4ad3dbb
      Michael Pyne authored
      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.
    • David Faure's avatar
      Fix error with phonon · 9a0a6f7a
      David Faure authored
  24. 06 Oct, 2020 1 commit
  25. 27 Sep, 2020 3 commits
    • Michael Pyne's avatar
      setup: Break out common 'options' blocks for kdesrc-build-setup to always use. · ed1545b7
      Michael Pyne authored
      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) s...
    • Michael Pyne's avatar
      setup: Make include-dependencies optional, show module groups not chosen. · 2317c3a3
      Michael Pyne authored
      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
      That fix will happen in a separate commit, this should hopefully make it
      easier to read through the generated kdesrc-buildrc in any case.
    • Michael Pyne's avatar
      qt5: Bump default version of Qt5 to 5.15. · 12da51a0
      Michael Pyne authored
      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
  26. 20 Sep, 2020 1 commit
  27. 19 Sep, 2020 1 commit
  28. 10 Sep, 2020 1 commit
  29. 05 Sep, 2020 1 commit
  30. 01 Sep, 2020 1 commit
  31. 23 Aug, 2020 1 commit
    • Michael Pyne's avatar
      xsession: Fix selection of wrong libname when a compat symlink is present. · 379a5249
      Michael Pyne authored
      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.
  32. 16 Aug, 2020 3 commits
    • Michael Pyne's avatar
      cmdline: Remove ancient dead code associated with cmdline reading. · de6fe8d6
      Michael Pyne authored
      This was all replaced with Getopt::Long years ago but I missed this
      during that refactoring.
    • Michael Pyne's avatar
      sample-config: Remove libdbusmenu-qt from default build. · 1681f3d3
      Michael Pyne authored
      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.
    • Michael Pyne's avatar
      bzr: Perform initial checkout from the base source directory. · cc0beb93
      Michael Pyne authored
      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 :)