GerHobbelt
Automated builds in releases
Hi, thank you so much for maintaining this fork! I got it up and running in a couple of minutes easily which is exceptional in C/C++ projects I have worked with.
I would like to help making automatic builds of the library and export distributable files for each necessary build config. Automatic builds and releases can then be triggered manually or whenever you push to master. I would like to develop this so that the maintainers of the project I'm working on (Hylo language) don't have to build pthreads from source, just copy the necessary files.
I've worked on similar automations in https://github.com/hylo-lang/hylo-dev-toolchain and https://github.com/hylo-lang/llvm-build If you have any input or suggestions on what matrix of options is it useful to build with, or any UX wishes, I would be happy to take it into account.
While I appreciate the intent (and pull reqs are always welcome, particularly for CI stuff), I have one 'objection':
personally, I push for any project (particularly any C/C++ one) I participate in to build everything from source; the reason being that I've been burned frequently and badly in the past, particularly on MSWindows systems, by hard-to-debug 'almost never happen, but if I do...' issues which originated from libraries and/or DLLs having been compiled with a subtly different compiler config then the rest of the build, so I tend to stay away from pre-built libraries myself.
Meanwhile, some working auto-build/CI scripting would be good to have, so that GitHub can run a test-build for me, rather than me doing it by hand. I don't like CMake (never have; it's a mess since the day it was born AFAIAC) but everybody uses that one, so any help providing a CMake library build config would be nice (particularly testing that the very thing works as advertised!).
Most of the time I'm using MSVC2022 (and its sln/vcxproj files), but otherwise my preference is to use meson-based builds, as that is much closer to what I expect from a build toolchain.
Just so you know where my preferences lie; I'm not saying you shouldn't do this, but from my POV building your 3rd party libraries from source is a good thing. -- This also matches with some other peculiar behaviours of mine, including code inspection when merging/tracking other libraries, while I sometimes adjust them to our needs: again, build from source is a bit of a hassle at first, but it has never let me down the way prebuilt libraries have, plus I 'know' I'll have some proper (up to date!) debug files to go along, so I won't run into surprises when debugging some nasty little bugger that happens to travel in & out of the 3rd party library codebase.
As a consequence of these preferences, I'm pretty fluent in git submodule workflows and have a bunch of helper scripts (bash, mostly) which I use daily, over at https://github.com/GerHobbelt/developer-utility-commands (in case you wonder).
