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

Wed Aug 28 05:30:37 PDT 2019

sammccall added a subscriber: MyDeveloperDay.
sammccall added a comment.

Sorry about the long delays in responses.
I don't think the feature, as you want to scope it, belongs in clang-format.
@klimek @MyDeveloperDay may have different opinions.

In D50147#1533892 <https://reviews.llvm.org/D50147#1533892>, @Typz wrote:

> In D50147#1533337 <https://reviews.llvm.org/D50147#1533337>, @sammccall wrote:
>
> > One thing that's unclear to me is whether your aim is to
> >
> > 1. solve a concrete problem for your organization
> > 2. solve a family of problems for similar organizations
> > 3. add a new way of configuring styles for many types of users/projects
>
>
> 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.

> 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.

> 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.

>> 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?

> 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 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.

Repository:
  rC Clang

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

https://reviews.llvm.org/D50147