GitLab

We don't want slashes in the runtime id affecting the build directories
being used.

If there are any slashes in any of the variables used to determine the
build dir, we need to replace them with hyphens so they don't
cause extra directories to be created.

We want to execute prebuild/postbuild as part of the build pipeline. This
registers launchers to be executed as part of that process.

This got messed up during refactoring.

This is more aptly named buildconfig so we will separate it from the
buildsystem module.

This moves some custom stuff (like command queues) to the buildconfig
subclass. We will also need to add a pipeline stage to attach these to
the proper build phase.

These were moved to providers, so we don't need them any longer here.

This was made subclassable, and we need to use priv now instead of self.

This went through a rename, so we need to rename various functions and
prefixes to match.

Now that IdeConfiguration is derivable, it makes more sense to have the
view for it in libide so it too can be subclassed.

https://bugzilla.gnome.org/show_bug.cgi?id=777959

This commit makes the IdeConfiguration mark itself as dirty when an environment
variable (or its value) is changed by the user, rather than just when an
env var is added or removed. That way such changes can be written back
to the disk (almost) immediately.

https://bugzilla.gnome.org/show_bug.cgi?id=777959

When the user changes build preferences in the Builder UI, those changes
should propagate back to the manifest file on the disk. This commit
accomplishes that in a somewhat hack-ish way (by reading the file
line-by-line and making changes where necessary) so that formatting,
comments, etc. are preserved that would be lost if JsonBuilder and
JsonGenerator were used instead.

https://bugzilla.gnome.org/show_bug.cgi?id=777959

This class provides the functionality that was previously in
IdeConfigurationManager, reading and writing .buildconfig files.

https://bugzilla.gnome.org/show_bug.cgi?id=777959

Some projects might want to put their flatpak manifest in a subdirectory
rather than the project's root directory, and the performance hit seems
negligible.

https://bugzilla.gnome.org/show_bug.cgi?id=777959

This class will allow GbpFlatpakConfigurationProvider to store more
information about manifests than it could with IdeConfiguration, such as
which module in a manifest is the primary one (rather than a dependency).

https://bugzilla.gnome.org/show_bug.cgi?id=777959

This will allow plugins that implement IdeConfigurationProvider to add
their own properties to the configuration objects. It has yet to be
determined if different types of configurations can have different UI
elements.

https://bugzilla.gnome.org/show_bug.cgi?id=777959

Now that flatpak manifests are configurations, we can go back to
specifying the actual runtime in our buildconfig.

https://bugzilla.gnome.org/show_bug.cgi?id=777959

Since flatpak manifests specify how to build a project, it makes more
sense for them to be configurations rather than runtimes in Builder. Now
that setup is possible since we have the IdeConfigurationProvider interface.

https://bugzilla.gnome.org/show_bug.cgi?id=777959

This changes IdeConfigurationManager to load configurations via the
IdeConfigurationProvider interface (which can be implemented by any
plugin) rather than checking for a .buildconfig file. The
IdeBuildconfigConfigurationProvider will provides backwards
compatibility for that functionality.

https://bugzilla.gnome.org/show_bug.cgi?id=777959

This interface will allow build configurations to come from any plugin,
such as the flatpak one.

https://bugzilla.gnome.org/show_bug.cgi?id=777959

A bunch of this is no longer necessary now that we have the build pipeline.
However, we need to merge it with configuration providers still so that
we don't overload the runtime as the source for configuration information.

This registers various flatpak stages into the build pipeline so that they
can ensure everything is setup to perform builds within the proper build
environment.

This removes the vast amount of tricky code we previously had and moves
it into a series of build stages to be attached to the build pipeline.

As the configuration will not change during the lifetime of the pipeline,
all of the work can be performed up front which should simplify some of
our issues with threading in the build process (by making it go away).

We can probably still simplify this further, but this at least gets
everything working.

I would like to see a transient stage added for running `make dist` to
perform tarball creation.

We no longer want IdeMakecache to be in charge of executing the
make -p -n -s process since that should be done anytime the configuration
changes (and therefore belongs in the build pipeline). This simply allows
us to create a new IdeMakecache from a makecache file on disk. We still
use the runtime to perform various other make commands (like determining
what needs to be rebuilt if a file changes).

This reduces the GCC diagnostics to simply register the regex for
extraction when the build pipeline executes. This means that we do not
need to many handlers for logs which should keep overhead low as we add
additional error formats (such as for vala).

This updates the build tools plugin to use the build pipeline to track
build progress and logging.

This is a simple build pipeline addin for cmake. It does not yet handle
things like extracting build flags or targets. Also, it uses the Ninja
backend for building since that seems to be the better performing version.

This converts the cargo operations into a series of build stages to be
attached to the build pipeline.

Nothing surprising here. Just converts the operations into stages to be
attached to the build pipeline.

We need this a bit wider so it doesn't jump around so much.

This should not be necessary going forward. But should it be, we can bring
it back.

This moves the build manager to use the new IdeBuildPipeline. We can drop
a bunch of things such as IdeBuildResult and IdeBuilder with this design.