Open marc-guenther opened 1 year ago
I agree with you. I'm still using v4.9.0 because building the weekly releases seems to be more trouble than I have time for. It seems very locked into "works on my machine" at this point. As of 8/2023 getting 504 Gateway Timeout just trying to download Boost via autogen... Surely it could be easier for non-maintainers to make a build...
I know this isn't a helpful comment, I just don't know where else to offer feedback. Watchman was really good about 3 years ago.
The Linux binary release isn't guaranteed compatible with every distribution. It has libc version requirements, and may only work on a range of Ubuntu releases, as you found.
We don't have the bandwidth to support builds for the long tail of Linux distributions, but I wonder if you could play with the release actions and see if you can get it to build an Amazonlinux-compatible release in a Docker image:
https://github.com/facebook/watchman/blob/main/.github/workflows/generate-release-yml.rs
https://github.com/facebook/watchman/tree/main/watchman/build/package
Since several years I have run watchman successfully in an Amazonlinux-2 Docker Container, by installing from the https://download.opensuse.org/repositories/home:crantila:watchman/CentOS_7/home:crantila:watchman.repo Repository:
Last month I needed to make some changes to the container, and the build failed, because that repository has vanished in the mean time. 😮
So I try to install the official binaries:
This then fails due to wrong glibc version:
I then tried to upgrade the container to Amazonlinux-2023, which has a higher glibc version, but it is missing the required openssl package:
I then tried to install through Homebrew, which blew up the size of my container from 180MB to 3.6GB, took like 8min to install, and in the end produced an executable which looks like it's working, but never notices even a single file change.
I then spent more than an entire day trying to compile from source code, because:
it seems I have to find out required packages by myself:
This initially (a month ago?) failed due to
cpp: too many input files
while compiling boost. I never got any further.Today as I wanted to report this, that error was gone, but a long time later it fails with:
This happens while compiling
fizz
, and has been reported here 3 month ago:As I already spent more than a day on this, and it was super slow, blew up my container size, and depended on like a million external dependencies, all of which had their own problems, I gave up at this point. This is a complete nightmare, and I don't want this in my build pipeline.
In the end, I extracted the binaries from the working container which luckily I had not deleted yet, and checked them into my Git repo:
This is the only thing that ever worked, and it's only 244KB. I have no idea where these binaries come from, and how they were built. But by now, I don't care anymore.
The full Dockerfile and a small test script is available here:
Lessons learned: