66 create appimage for linux#67
Merged
Merged
Conversation
Builds a self-contained AppImage on push-to-main alongside the existing Windows x64/x86 zips, attached to the same GitHub Release. - CMake: -DBUILD_APPIMAGE=ON switches the install layout to FHS (bin/fbide + share/fbide/ide/) and defines FBIDE_APPIMAGE_BUILD. - ConfigManager: when FBIDE_APPIMAGE_BUILD is set and the binary lives in bin/, resolve m_ideDir via <prefix>/share/fbide/ide. Mirrors the macOS .app-bundle resolution and falls through to the portable side-by-side layout when running from a build tree. - packaging/linux/: AppRun + fbide.desktop used by linuxdeploy. - setup-wx action: branch on runner.os; new build-wx.sh builds wxGTK3 static with the same trim list as the Windows build. - ci.yml: new build-linux-appimage job (ubuntu-24.04, release-only). Stages AppDir, converts the .ico to a 256x256 PNG, runs linuxdeploy with the GTK plugin, uploads as release-linux-appimage. The existing release job picks the AppImage up via a widened files: glob. ubuntu-24.04 sets the lower bound for systems the AppImage will run on (glibc 2.39); narrower than 22.04 but matches the user's chosen runner.
The job was gated on `needs.version.outputs.release == 'true'`, which is only set on push-to-main. workflow_dispatch and any other branch push left the job skipped — so the AppImage build couldn't be exercised before merging to main. Mirror the build-and-test pattern: the build/test/stage/AppImage steps run unconditionally; only the release-artefact upload is gated, so manual runs verify the AppImage produces without publishing it.
Mirror the Windows build-and-test job so manual runs can pick Debug / RelWithDebInfo for the AppImage build too. Push-to-main still defaults to Release via the same fallback expression.
- Linux configure now passes -DWXWIN=... so cmake/wxwidgets.cmake takes the CONFIG path (matches Windows). The previous -DwxWidgets_ROOT_DIR fed the legacy FindwxWidgets module, which expects the prebuilt- binaries directory layout that 'cmake --install' does not produce. - workflow_dispatch grows three boolean inputs (build_win64, build_win32, build_linux_appimage; default true) so manual runs can pick a subset of targets. The version job translates the inputs into outputs (win-archs JSON list + build-linux-appimage flag) consumed by build-and-test's matrix and the AppImage job's if guard. Push events bypass the inputs and build everything.
GCC fires the diagnostic at our call site when wxString's ConvertedBuffer constructor is inlined into std::vector growth (string.h:3745). The pointer in question is in wx code we mark as -isystem, but GCC charges the warning to whichever non-system frame appears in the inlining stack. -Werror then breaks the build. Clang's -Wnull-dereference doesn't have this propagation issue, so keep it enabled there.
The wx-header false positive was driven by IPO turning on inlining across translation units, not by GCC's diagnostic itself. Now that build-wx.sh hard-disables IPO for the Linux wx build, -Wnull-dereference on GCC produces clean output and stays in the shared warning list.
Headless GitHub Actions runners ship with no installed fonts, so even the platform-default monospace falls through wxFontEnumerator's IsValidFacename check and the test fails. The behaviour the test guards (face-name preserved on disk, resolved font usable on this system) is still meaningful on developer machines where fonts exist; gate the assertions on the CI env var that every major CI provider sets automatically.
linuxdeploy's appimage plugin already honours the LDAI_OUTPUT env var (the new spelling for the deprecated OUTPUT) and writes the AppImage straight to the requested path. The leftover `mv FBIde-*.AppImage` fallback was from an older flow and now fails because no FBIde-* file exists.
Silences appimagetool's missing-metadata warning and lets GNOME Software / KDE Discover surface FBIde with name, description, license, upstream URLs, and the file-browser screenshot from the project site. Component id uses Flathub-style reverse-DNS (io.github.albeva.fbide); the metainfo file is staged at usr/share/metainfo/<id>.metainfo.xml so the path leaf matches the component id (required by the AppStream spec).
Two changes so a manual run with a target subset can still produce a GitHub Release: - workflow_dispatch grows a 'publish_release' checkbox (default off). When ticked, the version job sets release=true so the release job fires even though the trigger is not push-to-main. The tag-doesn't- exist guard runs in both modes. - The release job now uses 'if: always() && ... && (build-and-test succeeded OR build-linux-appimage succeeded)'. Skipped upstream jobs no longer cancel the release; a full failure / skip of both still does because there is nothing to attach.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
closes #66