Can we have this on MacOS <12.0

[CurryKitten]

Is there an existing feature request for this?

• [X] I have searched the existing open and closed issues

Feature description

Hi there,

Not a bug, and not so much a feature request, but I wondered if you could make your MacOS packages for the largest range of OS's you can. Right now, it's 12.0+ Lot's of people held back on Majove because they want to still run 32-bit packages

[kirek007]

Sadly I don't have access to any MacBook so I can't make it work

śr., 10 maj 2023, 18:01 użytkownik CurryKitten @.***> napisał:

Is there an existing feature request for this?

• I have searched the existing open and closed issues

Feature description

Hi there,

Not a bug, and not so much a feature request, but I wondered if you could make your MacOS packages for the largest range of OS's you can. Right now, it's 12.0+ Lot's of people held back on Majove because they want to still run 32-bit packages

— Reply to this email directly, view it on GitHub https://github.com/avsaase/walksnail-osd-tool/issues/23, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOKQC4UJLUIQSYZM2KFP4DXFO3WTANCNFSM6AAAAAAX46AGBQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[avsaase]

I don't have a Mac that I can downgrade to test this with. Can you describe the issue you encounter when running the app and share the log file that's created in ~/Library/Application Support/Walksnail OSD Tool?

[CurryKitten]

The app doesn't open, so I don't get a log (or indeed a folder created) It works perfectly when I go ahead and build it myself on my 11.7.5 system. I also note that if I go into the contents of the package I downloaded from the releases and run walksnail-osd-tool directly from Contents/MacOS then it works fine - so this appears to be a packaging issue rather than simply the binary... but I'm afraid I don't know the ins and outs of MacOS packages well enough to say how to fix it

[CurryKitten]

Ok, so looking further at your environment, I presume you get GitHub to automagically build/package this for you via their VM's and your release.yawl et al.

Looking at the targets specifically -

targets:
          [
            {
              name: windows64,
              fancy_name: windows,
              runner: windows-latest,
              target: x86_64-pc-windows-msvc,
              ffmpeg_filename: ffmpeg-6.0-essentials_build.7z,
              ffprobe_filename: "",
            },
            {
              name: macos-intel,
              fancy_name: macos-intel,
              runner: macos-latest,
              target: x86_64-apple-darwin,
              ffmpeg_filename: ffmpeg6intel.zip,
              ffprobe_filename: ffprobe6intel.zip,
            },
            {
              name: macos-arm,
              fancy_name: macos-apple-silicon,
              runner: macos-latest,
              target: aarch64-apple-darwin,
              ffmpeg_filename: ffmpeg6arm.zip,
              ffprobe_filename: ffprobe6arm.zip,
            },

Right now macos-intel is building on macos-latest which is (according to this page https://github.com/actions/runner-images) MacOS-12. Obviously, your macos-arm target does need MacOS 12, but your Intel target doesn't and a package built on 11 should still work on 12 so a "quick hack" option is to switch the runner image to macos-11

Alternatively (and less hacky)... and I must admit to never touching rust before, but in the cargo-bundle docs, I notice that you can specify a osx_minimum_system_version to specify the minimum version of MacOS that the package supports. I can't find any docs about what happens when this is not specified, but going by what I'm seeing, perhaps this is set to the version of MacOS that the build runs on.

I'd be happy to test if this works using my MacOS 11 system, and a MacOS 12 VM, but although I can happily build the binary on the command line, the package part is eluding me. I installed binstall and then cargo-bundle but attempting to follow the yaml file through and running

cargo bundle --bin walksnail-osd-tool --release --target x86_64-apple-darwin --features macos-app-bundle

give me a error: No 'package' info found in 'Cargo.toml' error and I kind of get lost there.

[avsaase]

Thanks for looking into this. The fact that your able to run the binary within the app bundle point to a bundling issue so I think you're one the right track with that cargo-bundle option. I need to do some digging myself to figure that out over the weekend.

[avsaase]

Sorry for the delay but I finally found the time to look into this.

I split the project up into separate backand and ui crates to improve compile times and in preparation of a planned rewrite of the GUI using another library. However, cargo-bundle doesn't understand this workspace setup because the [package.metadata.bundle] is defined in the ui crate's manifest.

I pushed an update to the release workflow that does this and sets osx_minimum_system_version = "10.11". Can you try the latest build to see if it runs on MacOS 11? It has this in the app bundle Info.plist file so it hope it works:

<key>LSMinimumSystemVersion</key>
<string>10.11</string>

You can download it here: https://nightly.link/avsaase/walksnail-osd-tool/workflows/release.yaml/master/walksnail-osd-tool-all-platforms.zip

[CurryKitten]

Sadly, it was still wanting MacOS 12.0 or later. I can see the LSMinimumSystemVersion is set to 10.11 as you mentioned, but it doesn't seem to be helping. Again, the binary inside the package directory works fine when run in isolation.