This came up in discussions about getting my Snapcraft plugin for gnome-builder accepted upstream: they would like to be able to run the build for the main part themselves rather than have Snapcraft do it.
At first I was a bit reluctant to entertain this, since the last thing we want is to have some packages that can only really be built within an IDE (as could be the case with the Click SDK), but some of the arguments for it are compelling:
-
The gnome-builder devs want to add the features to programatically modify an {autotools, cmake, distututils, etc} project, so it is important that it can see the project’s main build system so we can take advantage of that.
-
The IDE wants to know what compiler flags a particular file in the project will be compiled with so that it can parse the file with libclang.
-
If you’re actively developing a code base, you want relatively quick incremental compile times. As things stand at the moment, direct changes to the source tree will require cleaning and redoing the “pull” stage for the part and a complete rebuild.
-
The devs were interested in adding the option to perform a second build pipeline to perform a standard build to give assurance that the package will build outside the IDE. They saw this as useful for Flatpak too.
So what sort of system am I envisioning? Projects that could benefit from this would need to satisfy a few constraints:
- The root directory of the Snapcraft project must also be a valid project for some other build system.
- There must be a part with
source: .
, which I’ll refer to as the “main part” - The main part’s plugin must match up with a build system gnome-builder knows about.
It shouldn’t be a problem if the Snapcraft project has other parts (either defined directly, or cloud parts).
The actual process of building the project would look something like this:
- Ask Snapcraft to perform all steps up to but not including the “build” step for the main part.
- Determine the build configuration for the main part. This should probably involve Snapcraft so things don’t get out of sync. This would include:
- flags passed to
configure
or the build system’s equivalent. - any environment variables that should be set.
- flags passed to
- Have the IDE configure and run the build, setting the build directory to
$root/parts/$partname/build
- Have the IDE install the project using a destination directory of
$root/parts/$partname/install
- Tell Snapcraft to assume that the part’s build step has completed successfully.
- Ask Snapcraft to complete the package build.
With a system like this, we can basically progress to (3) and then let the user repeat compile step as many times as necessary before continuing on to create their package.
Now I know that there are some open questions with a system like this (e.g. how should build
and install
scripts in the part be handled), so I’d appreciate any ideas or suggestions.