1. 16 Jun, 2018 1 commit
  2. 22 Mar, 2018 2 commits
  3. 24 Jan, 2018 1 commit
    • Christian Hergert's avatar
      config: refactor config providers to be less racey · 1ab088f0
      Christian Hergert authored
      We had a number of issues in practice with configuration providers where
      things would race and as well as some unsafe threading/false-sharing.
      This redesigns those components to avoid a number of issues in thread
      There doesn't seem to be any regressions. However, it has pointed out
      a few things that are/were broken in the flatpak configuration provider.
      We will address those as part of a revamped build preferences that is
      more pluggable (See #344 and #352).
      Another piece that would be nice to apply on top of this is tracking
      the last selected configuration so when restarting Builder we keep
      the same config active (See #338).
      Fixes #359
  4. 23 Jan, 2018 4 commits
  5. 11 Oct, 2017 1 commit
  6. 03 Oct, 2017 1 commit
  7. 21 Sep, 2017 1 commit
    • Christian Hergert's avatar
      source tree reorganization · 9b9db776
      Christian Hergert authored
      As the project has grown, we've let things get a bit out of their
      logical place. This does a bit of cleanup and tries to bring some
      of the embedded resources closer to where they are used.
      But more importantly, this allows us to clean some things up to
      the point that we can move forward statically linking a bunch of
      the plugins into libide. The plan here is to speed up the initial
      loading by avoiding lots of disk I/O stats which are currently
      hurting us.
  8. 17 May, 2017 1 commit
    • Matthew Leeds's avatar
      configuration: Make the default config persist · 39997b29
      Matthew Leeds authored
      When the build configuration management changed to using
      IdeConfigurationProviders rather than doing everything in
      IdeConfigurationManager, the default configuration stopped persisting to
      the disk (so changes made are only effective during a session). This is
      because the configuration was being added by the manager as an
      IdeConfiguration rather than an IdeBuildconfigConfiguration, and
      IdeBuildconfigConfigurationProvider knows how to read and write
      ".buildconfig" files.
      The most obvious solution, creating the default configuration in the
      IdeBuildconfigConfigurationProvider's load function, doesn't work because the
      loads are asynchronous and there has to be at least one configuration
      when the IdeConfigurationManager finishes initializing (otherwise the
      IdeBuildPipeline will fail to initialize).
      Instead, the load interface for IdeConfigurationProviders was changed to
      an async/finish pair, so the IdeConfigurationManager knows when the
      loads finish. At that point, it can check if a configuration was
      restored from a .buildconfig file (in which case nothing needs to be
      done) or if the default configuration was added by the
      IdeConfigurationManager (in which case the buildconfig provider needs to
      be informed of it so it can be persisted when changes are made).
  9. 10 Feb, 2017 1 commit