Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add AppImage build script #739

Merged
merged 1 commit into from
Jan 18, 2022
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
80 changes: 80 additions & 0 deletions tools/appimage/make-appimage.sh
Original file line number Diff line number Diff line change
@@ -0,0 +1,80 @@
#!/bin/bash

set -e
set -o pipefail

show_usage_and_exit() {
echo "Usage: $0 <dir>"
echo "<dir> is the location of an extracted no-installer linux tarball of Natron"
exit 2
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please say in the help that

should be the result of... extracting the no-installer linux binary distribution?
Actually, I would like it better if the script would even take care of extracting that distribution from a downloaded file into a temp dir, and cleanup the mess at the end

Copy link
Contributor Author

@TheAssassin TheAssassin Jan 6, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment seems broken, please revise.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please say in the help that <dir> should be the result of... extracting the no-installer linux binary distribution(?).

Actually, the script could even take care of extracting that distribution from a downloaded file into a temp dir, and cleanup the mess at the end.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could, but that doesn't make sense to me, really. It might make sense in your build infrastructure, though. I do not know how you plan to integrate this.

If you need such a script, you could add it as a second script which implements the downloading, extraction etc., and then calls this script. This script follows the Unix spirit, where there should be one tool for one job, and it should do that job well.

Copy link
Member

@devernay devernay Jan 8, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes you're right, we should run this script at the same time we build the tarball.
What I don't understand is that there seem to be a usr/ hierarchy in the tarball, but you leave most stuff out of it.

Shouldn't everything be moved inside usr/, rather than live in bin/ docs/ etc? What's the rule for AppImage?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for not replying in time. Feel free to move everything to a usr/ subdirectory. It's common for AppImages, maybe even "best practice", but not a requirement technically. I'll send a follow-up PR.

}

if [[ "$1" == "" ]]; then
show_usage_and_exit
elif [[ ! -e "$1" ]]; then
echo "Error: $1 not found"
show_usage_and_exit
elif [[ ! -d "$1" ]]; then
echo "Error: $1 is not a directory"
show_usage_and_exit
fi
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a check that verifies that the script is being executed on the right OS (I guess this is linux-only?) and architecture (x86_64 - we may support more in the future)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather require an $ARCH env var to be set instead, which can be evaluated in the last lines (where appimagetool is called). Detecting the architecture is horribly hard. In a CI script, one can easily add that environment variable manually, though. It's not subject to future changes.

The script can be run on any unix that can execute appimagetool (this includes FreeBSD with the linuxulator, I think). Limiting this to Linux does not make any sense to me. Could you please state how such a check would help you?


# "convert" extracted dir to AppDir
# this script is idempotent; existing files will be overwritten with the latest versions, subsequent runs will not change the outcome
pushd "$1" &>/dev/null

mkdir -p usr/share/{applications,icons/hicolor/256x256/apps,mime/packages}

# copy icons for desktop entry and MIME package
cp Resources/pixmaps/* usr/share/icons/hicolor/256x256/apps

# create desktop entry
cat > usr/share/applications/natron.desktop <<\EOF
[Desktop Entry]
Name=Natron
Type=Application
Exec=Natron
Icon=natronIcon256_linux
Categories=Video;
EOF

# create MIME package which the AppImage runtime can deploy
# copied from bin/natron-mime.sh
cat > usr/share/mime/packages/x-natron.xml <<\EOF
<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
<mime-type type="application/x-natron">
<comment>Natron Project File</comment>
<icon name="natronProjectIcon_linux"/>
<glob-deleteall/>
<glob pattern="*.ntp"/>
</mime-type>
</mime-info>
EOF

# copy files to AppDir root (would be done by tools like linuxdeploy, which we don't need for Natron)
cp usr/share/applications/natron.desktop .
cp usr/share/icons/hicolor/256x256/apps/natronIcon256_linux.png .

# fetch and store version number for use in the AppImage name
VERSION="$(bin/Natron --version | head -n1 | rev | awk '{print $1}' | rev || true)"
export VERSION

# create AppRun
[[ ! -f AppRun ]] && ln -s Natron AppRun
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As you suggested, the script should also expose NatronRenderer, how easy is it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Depends on how you want it to work. I think some graphics utility evaluated a --executable parameter, others use environment variables. Do you have a UX in mind?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I never used appimage. Can NatronRenderer be in the user PATH?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anything is possible. For instance, you could have a wrapper that calls the AppImage.

Think of an AppImage as a filesystem image with a runtime that FUSE mounts that image and executes a defined entrypoint.


popd &>/dev/null

# create AppImage

# storing appimagetool in temporary directory
tempdir="$(mktemp -d /tmp/natron-appimage-XXXXX)"
_cleanup() { rm -rf "$tempdir"; }
trap _cleanup EXIT

pushd "$tempdir" &>/dev/null
wget https://github.com/AppImage/AppImageKit/releases/download/continuous/appimagetool-x86_64.AppImage
chmod +x appimagetool-x86_64.AppImage
popd &>/dev/null

"$tempdir"/appimagetool-x86_64.AppImage "$1"