-
-
Notifications
You must be signed in to change notification settings - Fork 388
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 support to build AppImages on ARM #1564
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
AppImages can now be built for the ARM architecture. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
New projects will now use ``manylinux_2_28`` instead of ``manylinux2014`` to create AppImages in Docker. |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -44,7 +44,7 @@ def project_path(self, app): | |
|
||
def binary_name(self, app): | ||
safe_name = app.formal_name.replace(" ", "_") | ||
arch = LinuxDeploy.arch(self.tools.host_arch) | ||
arch = LinuxDeploy.arch(self.tools) | ||
return f"{safe_name}-{app.version}-{arch}.AppImage" | ||
|
||
def binary_path(self, app): | ||
|
@@ -175,13 +175,21 @@ class LinuxAppImageCreateCommand( | |
def output_format_template_context(self, app: AppConfig): | ||
context = super().output_format_template_context(app) | ||
|
||
# Add the manylinux tag to the template context. | ||
try: | ||
tag = getattr(app, "manylinux_image_tag", "latest") | ||
manylinux_arch = { | ||
"x86_64": "x86_64", | ||
"i386": "i686", | ||
}[LinuxDeploy.arch(self.tools.host_arch)] | ||
"aarch64": "aarch64", | ||
}[LinuxDeploy.arch(self.tools)] | ||
except KeyError: | ||
manylinux_arch = LinuxDeploy.arch(self.tools) | ||
self.logger.warning( | ||
f"There is no manylinux base image for {manylinux_arch}" | ||
) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why set the arch as "unknown" and printing a warning, so the next step fails (implicitly) on the Docker image lookup, rather than straight up failing on the arch lookup? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This one is a bit annoying....and I didn't want to introduce a bunch more changes to accommodate this better. First, this code runs even if someone passes Second, if someone isn't using the Briefcase template for AppImage, then the I don't think any of this is ideal....but I was mostly trying to avoid refactoring a bunch of this right now. Although, this really only presents because this is also introducing support for 32bit arm. If we only support aarch64, this complication (and others) goes away. This is the balance I landed on given all this....open to other balancing points. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah - I hadn't considered the |
||
|
||
# Add the manylinux tag to the template context. | ||
try: | ||
tag = getattr(app, "manylinux_image_tag", "latest") | ||
context["manylinux_image"] = f"{app.manylinux}_{manylinux_arch}:{tag}" | ||
if app.manylinux in {"manylinux1", "manylinux2010", "manylinux2014"}: | ||
context["vendor_base"] = "centos" | ||
|
@@ -190,9 +198,7 @@ def output_format_template_context(self, app: AppConfig): | |
elif app.manylinux.startswith("manylinux_2_"): | ||
context["vendor_base"] = "almalinux" | ||
else: | ||
raise BriefcaseConfigError( | ||
f"""Unknown manylinux tag {app.manylinux!r}""" | ||
) | ||
raise BriefcaseConfigError(f"Unknown manylinux tag {app.manylinux!r}") | ||
except AttributeError: | ||
pass | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should flag this change with a
removal
release note (in addition to the feature), as it's a notable change to defaults.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was on the fence about whether this should be a
removal
note since it will only affect new projects. Although, if someone familiar with the old behavior created a wholly new project, they very well could be surprised then.