[PATCH] D50147: clang-format: support external styles

[Francois Ferrand via Phabricator via cfe-commits]

Typz added a comment.

In D50147#1648786 <https://reviews.llvm.org/D50147#1648786>, @sammccall wrote:

> > First and forehand, I have a problem to solve in my organization : we have many projects, and maintaining the config file in some many repositories is not practical.
> >  In some case (like, LLVM, google or mozilla), this is not an issue because the formatting rules are hard-coded in clang-format.
>
> I think this option is available to anyone with a public style guide that covers a reasonably large body of open-source code, and which can be reasonably well supported by clang-format.
>  I'd expect QT, KDE etc should be able to use this mechanism.


unfortunately this is not open-source code, so we cannot modify clang-format :-(
hence the will to have the exact same behavior, but without modifying clang-format itself

>> In our case, we actually have more than one "standard" style, a combination of various OS (linux, windows, macos), and not a very strong control on user computers. So we cannot rely on a specific file or variable being setup by an administrator.
> 
> In this case my best advice would be in the short term to use .clang-format files. Longer term, some combination of using well-known styles, publicising and teaching clang-format about the styles you use, and gaining the ability to set environment variables would reduce duplication.

what do you mean about "gaining the ability to set environment variables" ?
in our case, we have around 500 repositories, so it really becomes a problem maintaining hundreds of copies of each style and verifying projects do not have a "variation" on one of the official style.

>> I think many orgs have the same issue, but some of them have found a solution by hard-coding their style in clang-format...
> 
> I'd like to see evidence that this is a widespread problem.

indeed I have no number at all.
But I think in many case, people would either:

- switch to a built-in style (which is not bad in itself, but can be problematic if there is lot of code already),
- not to use clang-format at all (which does not help with ensuring consistent formatting),
- or "fork" clang-format (which would we are currently forced to do, but is really not efficient)

>>> With that in mind, I'd be very happy to approve the build time config and/or an env variable, as long as they're off by default. It's easy to turn them on later, but not easy to turn them off.
>>>  If they're going to be on by default, I think we need a strong reason.
>> 
>> I they are going to be off by default, it means we would still need to patch clang-format to use it, correct ?
> 
> Sorry, by "off by default" I mean that if the environment variable is not set, there would be no default search directory. Relative paths would be an error.
>  So you could install styles centrally on each machine, and they would work if CLANG_FORMAT_STYLE_PATH was set, otherwise you'd get the fallback style. Would that be workable?



- Build option is implemented. This allows turn the feature off if needed, at build time (by specifying empty search path). I would prefer to keep thos
- Overriding an environment varialbe to change the search path is fine by me. But I would still prefer to have a "working" default, so that it can be used out-of-the-box, with no extra env variable to set

>> In D50147#1533337 <https://reviews.llvm.org/D50147#1533337>, @sammccall wrote:
>> 
>>> >> - understanding how distro packaging is going to work
>>>
>>> There's a mechanism, but how is it to be used? Will/should projects with a style guide provide style packages for distros? Or should these be part of the "official" clang-format package? 
>>>  If separate packages exist, how much is it going to confuse users that clang-format will silently format the same project with a `.clang-format` file different ways depending on what's installed?

The exact same thing happens today with clang-format's integrated styles.

But indeed this is an issue, and handling it would be my next step : once the concept of 'external style' is present, I'd like to allow referencing a style stored in remote git server or other URL, with clang-format handling the retrieval/update/cache.

>> The goal is to actually separate the styles from clang-format : so I don't see the point to make them part of the official clang-format package.
>>  Usage may be different: the styles may be setup through different packages (e.g. Qt style in qt-core package), installed manually by user, ....
>>  This is surely not perfect, since different packages may indeed provide the same style : technically this is not an issue (packages must just be marked as conflicting), but it is indeed the organisation's responsibility to use different names for the styles...
>>  (to some extent, this may be improved by passing URLs for external styles, e.g. from git ; but this may even be an issue if different mirrors must be used...)
> 
> The large majority of our users install clang-format through LLVM releases or OS distributors that repackage the same releases. There's no "the organization" to defer responsibility to; that's us.

The goal is indeed that user keep installing clang-format through  LLVM releases or OS distributors; but they would also install the custom styles they need, which would be provided by their organization (not clang/llvm!): e.g. Qt style, or "my-compagny" style.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D50147/new/

https://reviews.llvm.org/D50147