It’s no secret that one of the main features I wanted to land this cycle was introductory support for Xdg-App. There really was quite a bit to do to make that happen, including all sorts of seemingly unrelated plumbing.
One seemingly unrelated piece is the long-anticipated support for “Build Configurations”. I deferred on this feature for as long as possible because it needs to support many movable parts, for which we didn’t have a clear vision of. But now that our applications vision is becoming less and less murky, it was time to attack it.
IdeContext now contains an IdeConfigurationManager. This object can be used to get access to available configurations (IdeConfiguration). A configuration currently contains a target device (IdeDevice), a target runtime (IdeRuntime), environment variables (IdeEnvironment), and various other common properties.
We’ve ambitiously tried to avoid writing random dot files to your project, but time has come to add one. If you create a build configuration, we’ll drop a small .buildconfig GKeyFile in the root of your project tree. It contains the necessary information to bootstrap your project or build it with a given Xdg-App runtime.
Currently, we only have two runtime implementations. The default, is simply the host system. Think of it as a pass-through runtime. The second, is an Xdg-App runtime. It uses the runtime SDK installed via the xdg-app command line tool. For 3.22, I expect to have UI to install runtime SDKs.
You might imagine additional runtimes that we could create. Jhbuild is an obvious one, although hopefully it is less and less necessary now that we have a nightly GNOME SDK.
What do you think about automatically appending */.buildconfig to ~/.config/git/ignore?
I’m not sure, because I do think there is value in project maintainers being able to ship a default set of project options …
We need a good strategy to allow for developers to have custom changes to their .buildconfig, that doesn’t affect the checked in ones I guess?
One solution would be to have .buildconfig (in the global gitignore) which would be written by Builder, and buildconfig which would be checked in and only read and not written. Then settings from .buildconfig would override buildconfig, and changes to .buildconfig would not be annoying as they’d be ignored. Probably could think of a better naming scheme.
Anyway, my thinking is: you don’t want to pollute ‘git status’ with local changes to any file (either the Builder config file or the project’s .gitignore). And if we are going to be checking in these files to some projects intentionally, then Builder should not write to file automatically as then it would show up as a modified file in git status forever, and we could no longer use ‘git commit -a’.
My instinct would be to save users’ settings in gsettings instead, with a relocatable schema, but using a file has the advantage that you can copy the settings around more easily.
The problem with using GSettings and relocatable schemas is that key/value mappings are pretty horrendous in GKeyFile and not generally editable by hand (it just dumps a gvariant string iirc). I’d love to have this use the settings sandwich stuff, but it’s hard since we don’t have any sort of implicit “project” vs “personal overrides” here.
Note that we do not write back the file unless the user modified it. So you should not have a case of opening a new project, not changing anything, and then a new dot-file showing up.