GitLab

This function will allow us to check if a runtime is installed or install
it if the runtime could not be found (and a provider supports installing
the runtime).

This is meant to be used by the build manager to ensure that our runtime
is available before setting up the build pipeline.

This will create an IdeTransfer for the installation of a runtime and
execute it using the IdeRuntimeProviderInterface.intsall_async() vfunc.

This will allow us to locate a runtime provider that can install a runtime
from a known runtime-id (such as might come from a .buildconfig or flatpak
configuration).

Doing so will mean we can install missing runtimes as necessary before
setting up the build pipeline.

We want to avoid unnecessary property notification as well as ensure that
sdk and self->sdk are not the same pointers.

These give us the possibility to extend them from the configuration
standpoint which may be necessary in the future for certain configurations.

These are can be used to check to see if a configuration supports a
particular device or runtime. Ideally these will be used to filter the
list of available runtimes/devices in the build preferences so you can
only select valid options.

Allowing the build processes to inherit environment variables from the
Builder process can result in undesired behavior. For example if Builder
was run via "make run" LSAN_OPTIONS will be set, which causes an error
if the project is compiled with -fsanitize=address in CFLAGS.

This was lost during the pipeline transition. Without it, configure
complains.

We're not doing a full flatpak install to a repo, just building the app
and running the built binary. So this commit fixes the flatpak runtime's
create_runner function to use flatpak-build rather than flatpak-run.
In order to get the name of the binary, it was necessary to add a
get_name function to the IdeBuildTarget interface and implement it for
IdeAutotoolsBuildTarget.

If an IdeConfiguration (from buildconfig for example) is using a flatpak
runtime, the pipeline should still be able to do most things. This commit
changes GbpFlatpakPipelineAddin so it doesn't assume the configuration is
a GbpFlatpakConfiguration by getting platform, branch, and sdk from the
runtime instead and skipping parts of the pipeline (like building
dependencies).

This was dropped unintentionally

It makes more sense to have these be GbpFlatpakConfiguration properties
rather than using the internal data structures of IdeConfiguration. This
commit adds the properties to GbpFlatpakConfiguration, initializes them
in GbpFlatpakConfigurationProvider, and uses them in
GbpFlatpakPipelineAddin.

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