Not really a fan of this, even if it makes part of the development easier in a sense.

We've finally managed to get rid of binaries in the repo, just to check-in new binaries.

I'd rather try and improve the strictness of the required version or provide more guidance or implement some auto-format workflow or something in this direction.

Did we get rid of the dependency binaries because we believe pre-built binaries are inherently bad and should be avoided at all costs? If so, yes, this is dead in the water

I'd hope we did it because there was a better alternative that improves developer workflow. So look at the current workflow for formatting, reasonably assuming the majority of contributors won't have clang 17.0.6 set up in their environment:

• Find the correct clang-format binary. Best I could find was the github releases, so I had to download ~800MB of llvm+clang just to get a 3MB clang-format binary
• Reconfigure SFML to use that binary
• Build the format target

And i have to remember to do that every time I'm contributing, across multiple machines/platforms.

Using pre-built binaries means that workflow is just "build the format target", for every contributor, on every platform (and on CI).

Do you think the current workflow is better? Yes we could look at automating the formatting but I'm always a bit skeptical about having CI submit code changes

There were multiple reasons why we removed binaries and it's not that prebuilt binaries are inherently bad. Two of the big ones were:

• Building dependencies manually for every update for all platforms requires a ton of time, so we rarely updated the prebuilt binaries
• Each binary blob bloats the repository size. Adding more dependencies like we've done with HarfBuzz, would've added many MB more. Sure it's currently "just" 3.x MB per platform (why is there no Windows binary?), but those blobs need to be updated every so often, so overtime it still accumulates and inflates the overall repository size

I don't think SFML needs "to fix" the delivery channel of LLVM tools, but even so, I'd rather publish the tool somewhere and fetch it in CI, instead of adding it to the repository.

Yeah so the building dependencies argument is irrelevant as it doesn't apply here - The repo size is the reason i was expecting, and yeah I can't really argue against it as it's subjective. For me a few extra MB in the repo to improve the workflow of almost every contributor is worth it.

Fetching the binaries when configuring cmake was an option I considered, but couldn't see a way to avoid the 800MB download without hosting our own binaries somewhere - if you are able to host them somewhere suitable I'm happy to update this PR to do that.

On the subject of updating it periodically - I expect that's going to happen quite rarely, as it would also involve reformatting the whole source code, but I also think pre-built binaries are an improvement here as we would be able to use a version which has our preffered formatting, rather than one which is conveniently available in CI (which I believe is why we're on the current version?). And of course, we can prune the blob history as part of that update process so the concern about history size is easy to solve

Even though it puts more maintenance work on us, I could see us creating a separate repo that distributes the binaries either in GitHub releases or in the repo itself, including the necessary license notice to comply with Apache License v2.0.

If the expected format version doesn't match, we could then conditionally download the format binary and ensure that the right executable is used.

I don't see much benefit in doing that, but it's still an improvement on the current situation so happy to run with it if it's a suitable compromise

I've PoC-ed this idea with a separate repo that has the binaries as GitHub release, here: https://github.com/eXpl0it3r/clang-format/releases

One could use it like so:

FetchContent_Declare(
    clang-format
    URL "https://github.com/eXpl0it3r/clang-format/releases/download/llvmorg-18.0.0/clang-format-windows-x64.exe"
    DOWNLOAD_NO_EXTRACT TRUE
)
FetchContent_MakeAvailable(clang-format)

Thanks - have updated so that if clang-format isn't found (or isn't the correct version) it will download the required version from that repo

Have rebased onto latest master and set ready for review

If we don't want to use this approach I still think we should consider other options to make it easier for contributors to handle formatting (and maybe analysis too) locally