1. 24 Feb, 2019 4 commits
  2. 20 Feb, 2019 1 commit
  3. 18 Feb, 2019 2 commits
  4. 09 Feb, 2019 3 commits
    • Michael Pyne's avatar
      Merge branch 'add-qt5-support' into 'master' · 991f4e1f
      Michael Pyne authored
      Add support for building Qt5 modules.
      
      See merge request kde/kdesrc-build!3
      991f4e1f
    • Michael Pyne's avatar
      Add support for building Qt5 modules. · 11490810
      Michael Pyne authored
      This commit adds basic support for building Qt5 using the Qt5 support
      documented at https://wiki.qt.io/Building_Qt_5_from_Git as requested in
      issue #16 (and a dependency for #15).
      
      Architecturally within kdesrc-build, Qt5 is handled as a special type of
      module-set, in the same way that KDE project modules are special-cased
      using 'kde-projects'. For Qt5, we use 'qt-projects', and reuse the
      existing use-modules and ignore-modules options.
      
      The first difference is that {use,ignore}-modules applies to Qt's git
      *submodules*. We pass the combination of those to Qt's `init-repository`
      script as a module-subset. Currently the user will need to enter at
      least a use-modules declaration for other reasons, so we would want to
      setup a sample qt5 configuration to include something appropriate.
      
      Qt5 support also involves a dedicated source code updater (based on the
      basic Git support already present) and a dedicated build system. The
      source code updater handles the Git update for the qt5 "supermodule"
      containing `init-repository` and then calls `init-repository` to
      complete the rest of the process.
      
      Unfortunately the existing async IPC code doesn't play well with this
      but the worst that happens is that kdesrc-build will have 2 updates
      running at once for a time (kdesrc-build will think all of Qt is updated
      once the supermodule is updated).
      
      The build system is actually fairly standard compared to the other
      changes.
      
      There's a lot that's still missing here, including:
      
      * documentation,
      * real support for Git submodules (an open feature request for a long
      time),
      * the per-distro list of Qt build dependencies not handled by
      kdesrc-build, and
      * support for things like Qt's `qt5_tool`.
      
      But, it's successfully built for me with Qt 5.12. :)
      11490810
    • Michael Pyne's avatar
      first-run: Add Fedora 29 packages and installer metadata. · 34cef6ec
      Michael Pyne authored
      This package set is sufficient to get kdesrc-build --metadata-only to
      work, and assuming Qt 5 is installed, to get through kcoreaddons, maybe
      a bit further.
      34cef6ec
  5. 08 Feb, 2019 1 commit
  6. 13 Jan, 2019 1 commit
  7. 12 Jan, 2019 2 commits
    • Michael Pyne's avatar
      test: Add plumbing to allow for tracepoints during test. · d9f11a3e
      Michael Pyne authored
      I had added this while searching for the cxxflags bug. I break it up
      into a separate commit because it wasn't actually related to the
      cxxflags bug, but I still think it would be useful.
      d9f11a3e
    • Michael Pyne's avatar
      Fix cxxflags being set to a space when globally empty. · b01505be
      Michael Pyne authored
      When cxxflags is globally set to an empty value, the getOption magic
      that appends module values to global values for cxxflags causes it the
      result to equal ' ' (i.e. one space). This is because the space is a
      separator between two empty values.
      
      This causes code testing against cxxflags to think it's actually been
      set to a value and to add it in the cmake calls.
      
      I fix this and add a test case, but also add some insurance by trimming
      leading/trailing white space so that the existing check for empty
      cxxflags would have had a chance to catch this.
      
      Differential Revision: https://phabricator.kde.org/D18165
      b01505be
  8. 06 Jan, 2019 1 commit
    • Michael Pyne's avatar
      first-run: Add basic installer and packages for Debian distros. · 845e9da4
      Michael Pyne authored
      This adds the installer to allow Debian-based distros to run and a basic
      set of packages needed to at least allow kdesrc-build to successfully
      run --initial-setup, as tested under a Docker image of debian 9.
      
      This will still miss the dependencies required to fully make it through
      any kind of reasonable KDE software build. In particular even if I
      included the list of Qt modules that Debian 9 stable has available, they
      are too old for current git-based applications. But other modules are
      probably needed and still missing (suggestions accepted! :).
      
      So there's still more to do here, which is why the bug remains open.
      
      See issue #15
      
      CCBUG:402901
      845e9da4
  9. 30 Dec, 2018 1 commit
  10. 29 Dec, 2018 3 commits
  11. 28 Dec, 2018 3 commits
  12. 27 Dec, 2018 4 commits
  13. 26 Dec, 2018 2 commits
  14. 25 Dec, 2018 1 commit
    • Michael Pyne's avatar
      Fix broken cmdline parsing when --stop-on-failure in use. · e743b5bb
      Michael Pyne authored
      As reported in bug 402509, as position of command line argument changes
      the module build list.
      
      What was happening was --stop-on-failure in particular could 'eat' the
      next command line argument, because even though it was manually
      specified as a 'flag' argument to Getopt::Long, the 'stop-on-failure'
      entry was then overridden in the function call to read options by
      including the options in ksb::BuildContext::defaultGlobalFlags.
      
      A coding error on my part caused this inclusion of options to treat the
      options as requiring string values instead of boolean flags. As a result
      Getopt::Long would read the next non-option value and assign it to the
      'stop-on-failure' result.
      
      Fixed by treating the included flags as boolean flags instead of string
      valued, and by ensuring that the two sources for cmdline options are
      fully disjoint. I also added a test that fails with the old code and
      works with the new.
      
      Fixes #8
      
      BUG:402509
      FIXED-IN:19.01
      e743b5bb
  15. 21 Dec, 2018 2 commits
    • Michael Pyne's avatar
      Try to streamline 'quick start' documentation. · a7090fc7
      Michael Pyne authored
      This should document really almost everything the user needs to do to
      get started with kdesrc-build.
      
      The big thing missing is the .setup-env parts. I think that should go in
      kdesrc-build-setup but that's a separate discussion.
      
      Either way, once the documentation is accurate that should help in
      determining which features to include in kdesrc-build to be able to make
      this documentation even simpler so that we can broaden the base of users
      able to be productive with this and related tools.
      a7090fc7
    • Michael Pyne's avatar
      cmdline: Make -v stand for --version, not --verbose. · d285496c
      Michael Pyne authored
      A user mistakenly running "kdesrc-build -v" would otherwise be in for
      quite a surprise.
      d285496c
  16. 05 Dec, 2018 2 commits
    • Gregor Mi's avatar
      Add .arcconfig · 1c39943b
      Gregor Mi authored
      Reviewers: mpyne, dfaure
      
      Reviewed By: mpyne
      
      Differential Revision: https://phabricator.kde.org/D17291
      1c39943b
    • Michael Pyne's avatar
      Apply a consistent ordering of module list generation. · 671140a6
      Michael Pyne authored
      This fixes one of the most annoying outstanding issues with
      kdesrc-build. Though if I had known it would be this easy I'd have done
      it sooner.
      
      The issue is that running the same build command, with the same
      dependencies applied, would often come up with different build orders.
      
      $ kdesrc-build -p --print-modules --resume-from kcoreaddons
       ... build list shown
      $ kdesrc-build -p --print-modules --resume-from kcoreaddons
       ... a different build list shown
      
      The major cause of this is that the implicit ordering is derived from
      how the KDE project modules are loaded, using a filesystem search.
      Sorting the list of loaded modules when doing a search through the KDE
      project hierarchy is enough to handle this.
      
      A more theoretical issue is that the loaded dependencies themselves
      could be reordered even though the dependencies haven't really changed.
      To pre-emptively address this before the next kde-build-metadata cleanup
      we also canonicalize all loaded dependencies into a sorted order.
      
      Test suite passes.
      671140a6
  17. 02 Dec, 2018 1 commit
    • Gregor Mi's avatar
      Don't set DCMAKE_BUILD_TYPE in kf5-frameworks-build-include · 78a666fd
      Gregor Mi authored
      Summary:
      In kde/src/log/2018-12-01-04/kconfig/cmake.log, I found this:
      
      ```
      # kdesrc-build running: 'cmake' '/home/gregor/kde/src/frameworks/kconfig' '-DCMAKE_CXX_COMPILER_LAUNCHER=ccache' '-GNinja' '-DCMAKE_BUILD_TYPE=Debug' '-DBUILD_TESTING=TRUE' '-DCMAKE_BUILD_TYPE:STRING=debug' '-DCMAKE_CXX_FLAGS:STRING=-pipe ' '-DCMAKE_INSTALL_PREFIX=/home/gregor/kde/usr' '-DCMAKE_PREFIX_PATH=/usr'
      # from directory: /home/gregor/kde/build/frameworks/kconfig
      -- The C compiler identification is GNU 8.2.1
      -- The CXX compiler identification is GNU 8.2.1
      ...
      
      ```
      
      Note, that CMAKE_BUILD_TYPE from my global .kdesrc-buildrc gets overridden from "Debug" to "debug". For me, this came surprising (also the lowercase "debug" is less common than the capital D).
      
      This change  removes the definition of CMAKE_BUILD_TYPE from kf5-frameworks-build-include.
      
      Reviewers: mpyne, dfaure
      
      Reviewed By: dfaure
      
      Differential Revision: https://phabricator.kde.org/D17290
      78a666fd
  18. 23 Nov, 2018 5 commits
  19. 18 Nov, 2018 1 commit