Distribute binaries, including a drop-in replacement for the shared library

Thanks for publishing this.

I see the release process is fairly automated, is it possible to use CI to automatically build binaries of this, and publish them as releases? I don’t have experience in Github Actions, but I do in Gitlab CI. Both containers take 3 GB, but the binaries themselves are only ~7 MB.

Another interesting build artefact would be to “bake in” the settings in curl_ff95 script in the build itself, and create a regular curl shared library. This could replace with the upstream libcurl file to use the new settings, or hacked around with LD_LIBRARY_PATH. It would need to be a different build per browser.

Now curl is built in static mode. The library itself is in lib/.libs/libcurl.a.

[lwthiker]

I’m working on a Makefile-based build that will compile curl-impersonate natively, without the Docker containers. Once this is up and working it’ll be possible to add GitHub Action to automatically compile to MacOS and Linux and add the binaries to the releases

[lwthiker]

Thanks for the suggestions.

I agree about libcurl, I believe many would find it useful. If we “bake in” all the settings directly it would result in many copies of libcurl, one for each browser version. If we support 10 Chrome versions then we’ll have 10 different libcurls. Maybe a better solution would be to add a function to libcurl that configures everything the right way? But then LD_LIBRARY_PATH wouldn’t work as you suggested.

I used GitHub Actions for small projects only; I don’t know if it supports our heavy builds for free. Worth a try I guess. Would be good to have it to automatically check PRs, together with the new testing infra (https://github.com/lwthiker/curl-impersonate/pull/9).

About publishing, I’m not sure whether the binaries would be useful by themselves, as they are compiled for a specific Ubuntu/Debian and have external dependencies. Maybe publishing a .deb/.rpm package? I’m really not a packaging expert though.