Pass a --collection-id argument through to `flatpak build-export`.
Also add a ‘collection-id’ property to manifest files, which can be used
to set the collection ID on an exported repo (when using --repo) without
having to provide a command line option.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This allows you to automatically install/update dependencies required
by the manifest. The dependencies include:
Runtime, Sdk, Base, Sdk Extensions and Platform Extensions
There is also a --install-deps-only switch to make the build
stop after the dependencies are installed.
Fixes https://github.com/flatpak/flatpak/issues/955
Instead of constantly looking at the option we change the
manifest value if its unset. This means we can access the
default branch outside of builder-main.c, and that we get
it into the serialized manifest in the build.
Instead of mixing the source bundling with the build we make
it a separate step at the end, with cache support just like the
other stages.
Being at the end means we can reuse the cached stages from the
build if we enable bundle-sources after an existing build.
Also, this changes how the json and local files/patches are stored.
Now they are in a subdirectory called "manifest" in the sources
directory, with proper handling of relative pathnames for included
modules, etc. This also means we don't look for these file in the
extra-sources directory, but rather next to the json like we
do normally.
This adds a step to the build process to bundle
the module sources, used for building the flatpak,
as a runtime extension.
The sources can then be installed like the
debug or translation runtime.
This also adds an option to flatpak-builder
for specifying sources directories. One can specify
source dirctories with the use-sources argument. This
will skip the download part of the processing
and will extract the sources from the given sources
directory directly for further processing.
Those source directories do need the same
structure as the ones that flatpak-builder
creates during processing in .flatpak-builder
and which is also used in the exported sources
runtime.
This changes what files we look at to only those in this module,
which is generally right, but to handle the base-layer sdk
case we also have to run the python fixup in the initial layer.
The --allow-missing-runtimes options will allow flatpak builder to
not abort immediately if the sdk or runtime for the app being built
are missing.
This option will be useless when building anything in the modules
section of the app manifest. The calls to flatpak-build will fail
because of the missing sdk.
However, it may be useful when an application does not require
building anything inside the sandbox, and the application files
will be installed via other means.
This includes a few different changes:
* Add build-runtime boolean property
* Rename "app-id" property to "id"
* Add metadata property to use a custom base metadata file
* Default to writable-sdk to TRUE for runtimes
* Default prefix to /usr for runtimes
* Put manifest in usr for runtimes
* Pick up debuginfo from usr for runtimes
* Make build-finish work on runtimes, but only export appdata
Philip Withnall