-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
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 GitHub Actions workflow for release builds #5306
Conversation
Awesome, great work, Romain. I'm recovering health-wise right now which might take a while so will be mostly offline for the near future :/ |
I've added macos build job + modified makefile in my fork at dur-randir@6c4c2c3. The next question is, this generates unsigned binaries - e.g. you either have to provide a signing key (see https://docs.github.com/en/actions/use-cases-and-examples/deploying/installing-an-apple-certificate-on-macos-runners-for-xcode-development) or a user have to perform additional steps after download (like brew does automatically when installing from casks). |
amd64 aka x86_64 build actions config ? I can't see them there. |
@dur-randir Thank you very much! A few questions/remarks:
I'll read about signing keys later. |
Sure, I've done it separately because of I didn't know in advance what'd be needed to be changed. There's dievergence just in two places - additional args list for configure
They're taken from
Yes and no. I've tried (again!) to make a fully static build (link ffmpeg + libusb + libsdl) but I don't know meson at all and it broke somewhere down the road while double-linking _sha_$whatever while I was trying to shove them all together and then I ceased trying. Without static linking with those dependencies, one must relocate all libraries to be searched by relative paths by DYLD (they're baked by absolute paths by default on macos). IIRC this can be done with native instruments, but they're non-recursive, so I've picked one tool that works recursively out-of-the box. Another one tool is https://github.com/auriamg/macdylibbundler which can be installed from brew. Or create this recursive hand-written loop for path change. Or ideally make a fully static build, but I've given up. If you know meson, maybe you can create a recipe for at least linux, so I can tweak it for macos? |
👍
OK 👍 In the end, I think we want to build them without depending on brew.
Indeed, the native tool seems to be For windows, the scrcpy builds have 6 dll (so these libs are linked dynamically):
I think the macOS build could do the same, there would be no need for finding dependencies recursively. |
Here, i added for MacOS x86-64 thanks to @dur-randir db01900 |
Awesome, you ROCK, @Genxster1998 - big THANK you 👍 ! These two script files come in handy 😉: assign icon.png to scrcpy binary.zip
|
.. and for those who like it as a native macOS app 😀: |
@LeeBinder , you won't need a launcher to furnish path to scrcpy-server as it has been set default to executable_path already rather than /opt/... so no need envt. just adb,scrcpy,libs,server in same dir after patching binary for icon. i think *.dylib(s), adb and scrcpy-server can be moved to Frameworks in proper macOS app.
|
@Genxster1998 ideally, but it's not working (yet). Because when I simply double-click the scrcpy binary even if scrcpy-server IS present in the same directory, I get:
Try it yourself, please. Looks as if you need to add something in the compile/ build script so that scrcpy indeed DOES look in the same directory. Something is still missing. |
The option is Line 4 in 665ccb3
(add However, the code to find the executable path is not implemented for macos: scrcpy/app/src/sys/unix/file.c Lines 64 to 67 in 665ccb3
|
@LeeBinder Thats true indeed , Launching app from launchpad or Finder is not working. I tried adding |
I see. Agreed, should eventually be in ../Resources (neither in ../Libraries nor in ../Frameworks because it's neither of those but a Android executable binary) |
The scripts to build dependencies are currently specific to cross-compile Windows from Linux. I'll have to adapt them to also support native build (will be useful for macOS). Meanwhile, I can merge this PR. |
Since commit 2687d20, the Makefile named release.mk stopped handling dependencies between recipes, because they have to be executed separately (from different Github Actions jobs). There is no real benefit using a Makefile anymore. Replace them by several individual release scripts for simplicity and readability. Refs Genymobile#5306 <Genymobile#5306>
See #5515. |
Since commit 2687d20, the Makefile named release.mk stopped handling dependencies between recipes, because they have to be executed separately (from different Github Actions jobs). Using a Makefile no longer provides any real benefit. Replace it by several individual release scripts for simplicity and readability. Refs #5306 <#5306> PR #5515 <#5515>
Better late than never (#4490), I finally worked on a GitHub Actions workflow to build scrcpy releases.
I had to refactor the
release.mk
makefile to parallelize server and client build jobs. It is only run manually to build a release (not on push or pull request, I don't need it for now).In the end, it produces a zip artifact containing:
scrcpy-server-XXX
scrcpy-win32-XXX.zip
scrcpy-win64-XXX.zip
SHA256SUMS.txt
where
XXX
is the input name you give when you manually start the workflow (if empty, it uses the ref name, for example the branch or tag name).To test it:
master
branchmaster
branch, choose a version name (for examplev42
)For now, it generates the same targets as
./release.sh
did locally (scrcpy-server, release win32, release win64).The goal now is to add more jobs, especially:
.deb
Package Build and Release for Multiple Distributions #4427)Your help is welcome! ❤️
Now that scrcpy-server is generated separately once and for all, it will be easier to write the jobs for building the scrcpy client for different targets (Android SDK is not needed).
As an important constraint, the jobs MUST only reference "official" github actions (or dockers images), not actions/images from random users. Keep it as simple as possible.
Fixes #4490
Refs #2256 (comment) and next comments (cc @dur-randir @LeeBinder @Coool)
Refs #1709 (cc @dylanmtaylor)
Refs #3721 (cc @qmfrederik)
Refs #4427 (cc @hacksysteam)
Refs #4489 (cc @Gary-Cod)