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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits