How to maintain a .clang-format file for different clang-format versions?

Question

This question extends Unify output with different clang-format versions. The problem is that the default behavior of clang-format varies for different version, even for the built-in styles. Quite frankly, I would like to ask why the developers did not care about compatibility here but that is beside the point. The situation is as at is, and I must deal with it. I am not allowed to require a certain version of clang-format (like one user suggested in the related answer) and need to configure clang-format so that it gives the same results for different versions. If possible, the versions >= 4.0 should be covered. If this is not feasible, a solution that works for version >= minimum_version would be acceptable.

I guess one can find out a configuration for each clang-format version that gives the desired output -- tedious work, but at least it is a solution. But using the same .clang-format file for different versions yields some problems, as newer keys are unknown to the older versions. So one would need either

• A switch for clang-format that skips keys if they are unknown
• A way to pass additional options to clang-format (in addition to options given in a file)
• A way to specify the configuration file for a given clang-format version
• A nice way to do one of the a above (not sure what clang-format offers here)

Any ideas?

Answer 1

Since this has been open for a while and noone has attempted an answer, I will try to chip in with my 2 cents, based on my, admittedly limited, experience.

I suspect the reason this has gone unanswered for so long is because you can't really do it, and the only real solution is to force everyone to use the same exact version of clang-format. In the meantime, here are a couple ideas you could try:

1) If you can't force everyone to upgrade to the latest version, can you force a downgrade to a common/minimum version and just use that?

2) Can you live with everyone using their version of clang-format on their local machines, formatting only the lines they touch, and having a CI job that automatically updates the formatting to the "canonical" version after every commit?

3) You can try using only the features supported by the minimum version, and creating a separate configuration file for each later version, never relying on any default values or values set by one of the default styles, instead setting every configurable option manually. This will probably not work long term, though, especially if there are contributors always keen on using the head of the clang-format development branch.

And finally, the only option I would really consider, short of forcing everyone to update to a specific version of clang-format:

4) Write a wrapper around clang-format, make everyone use that. I'm assuming none of your developers are locked out of running the actual code you produce on their development machines, or you have at least one tool/scripting language that can run code shared for all developers? Then just use one of the production/tool scripting languages you already have in place, to write a wrapper around clang-format. Forward all the input (command line parameters, stdin, upload any referenced files, etc) to a server running your "actual" clang-format instance with the correct configuration, have it do the formatting, and forward all the output (stdout, stderr, contents of any modified files, return code, etc) back to your wrapper, and have it replicate the changes on the local machine. If done well enough, no tools/IDEs/etc integrating with clang-format should be able to tell the difference. Instance enough of these clang-format servers close enough to your developers, as needed, to handle any latency issues and peak usage cpu/network load - have a server or a couple of servers per office, maybe even instance a small, low memory footprint linux server VM on each of your developers machines. Maybe have the server automatically pick up new versions of clang-format and the configuration. Yes, there will be more latency compared to running clang-format natively, but I think it's the best you can do in your circumstances, and has the added benefit of everyone being on the same, up to date, version of clang-format that you can change/configure at will, without worrying about pushing the changes out to every contributer and whatever limitations they might have on their machines.