Rationalise building section #98
Conversation
docs/building-basics.rst
Outdated
|
|
||
| Runtimes require regular maintenance, and application developers should generally not consider creating their own. | ||
|
|
||
| Once you have chosen a runtime for your application, you will need to install it. Runtimes are installed in exactly the same way as applications, with the ``flatpak install`` command. For example, the command to install the GNOME 3.26 runtime is:: |
There was a problem hiding this comment.
It may be worth noting end users do not need to manually install runtimes. And actually developers don't need to either if they specify --install-deps-from=flathub when using flatpak-builder.
docs/first-build.rst
Outdated
| Each Flatpak is built using a manifest file which provides basic information about the application and instructions for how it is to be built. To add a manifest to the hello world app, add the following to an empty file: | ||
|
|
||
| .. code-block:: json | ||
| The input to ``flatpak-builder`` is a JSON file that describes the parameters for building the application. This is called the manifest. The following example is the manifest for the GNOME Dictionary application:: | ||
|
|
||
| { |
There was a problem hiding this comment.
You should keep -.. code-block:: json for syntax highlighting.
| "sdk": "org.gnome.Sdk", | ||
| "command": "gnome-dictionary", | ||
| "finish-args": [ | ||
| "--socket=x11", |
There was a problem hiding this comment.
I realize you are trying to be minimal but this leaves some bad habits like not including --socket=wayland and --share=ipc for Gtk3 applications.
There was a problem hiding this comment.
The only reason those are the only sandbox permissions in the example is that they're what's in the manifest I inherited. I'd love to have a better demo with a sane set of options in it (that's #97)!
There was a problem hiding this comment.
All Gtk3 applications will have like 7 or so permissions to just be fully functional.
docs/manifests.rst
Outdated
| Add a section on specifying the list of modules. There has to be something to say here... | ||
| - ``rename-icon`` - rename the application icon | ||
| - ``rename-desktop-file`` - rename the ``.desktop`` filename | ||
| - ``rename-appdata-file`` - rename the AppData file |
There was a problem hiding this comment.
You should note that these should not be relied upon by upstreams and they should always rename their files there. That fixes subtle mistakes like icons being referenced internally and such. And some things like the app-id in code cannot be automagically renamed.
There was a problem hiding this comment.
If that's the case, should I just remove the entire section on file renaming?
There was a problem hiding this comment.
They certainly need to be documented because a lot of applications use it, there just needs to be clear information on the better solution like #99
There was a problem hiding this comment.
Alright, I've just added a note for now.
docs/manifests.rst
Outdated
| @@ -51,7 +60,7 @@ A list of ``finish-args`` options can be found in :doc:`sandbox-permissions`. | |||
| Cleanup | |||
| ------- | |||
|
|
|||
| After building has taken place, ``flatpak-builder`` performs a cleanup phase. This can be used to remove headers and development documentation, among other things. Two properties in the manifest file are used for this. First, a list of filename patterns can be included:: | |||
| The cleanup build can be used to remove files that are produced by the build process but which aren't wanted as part of the application, such as headers or developer documentation. Two properties in the manifest file are used for this. First, a list of filename patterns can be included:: | |||
There was a problem hiding this comment.
The cleanup build
cleanup property.
docs/manifests.rst
Outdated
| "url": "https://download.gnome.org/sources/gnome-dictionary/3.26/gnome-dictionary-3.26.0.tar.xz", | ||
| "sha256": "387ff8fbb8091448453fd26dcf0b10053601c662e59581097bc0b54ced52e9ef" | ||
| } | ||
| ] |
docs/manifests.rst
Outdated
| - ``script`` - an array of shell commands (these are put in a shellscript file) | ||
| - ``patch`` - a patch (are applied to the source directory) | ||
| - ``extra-data`` - data that can be downloaded at install time; this can include archive or package files | ||
|
|
allanday
force-pushed
the
building-improvements
branch
from
8ab8648
to
70d2f84
Compare
allanday
force-pushed
the
building-improvements
branch
from
70d2f84
to
3825566
Compare
There's a fair amount of technical content here, which would benefit from being checked.