On Sat, 10 Oct 2020 at 23:39, Even Rouault <[email protected]> wrote: > > > However, I found it strange that there is no automatic formatting with > > clang-format for C++ code. > > > > In this page > > https://gdal.org/development/rfc/rfc69_cplusplus_formatting.html it is > > suggesting to use it. That would be great! Enabling it in your favourite > > editor makes the code nicer, without any extra work. And more consistent! > > > About "when" to apply it (reformatting *all* the existing code), I think a > > good moment could be just before creating a "big" release branch, like 3.2. > > Then the backport of bug fixes would be easy (otherwise it is a nightmare). > > > > What do you think? > > > Was discussed at that time in > https://lists.osgeo.org/pipermail/gdal-dev/2017-May/thread.html#46560 > > I would be quite in favor of the principle > > A few points I've in mind: > > - I'm slightly worried about clang-format output changing between versions of > the tool (based on my experience with PROJ, I can tell you that they are > different between 3.8, which is the one we used for PROJ, and 10), which > would be an issue as we cannot be certain that our set of contributors to > have different versions. Not sure if having a custom .clang-format file > (possibly a 'standard' one that we put in our tree to make output stable) > would help ? This would have to be investigated & tested.
I think, it would require us to stick to a particular clang-format version that is allowed to (re)format GDAL. Contributors who want to use clang-format would have to use the decided version only. I suspect, higher versions of clang-format systematically suffer from less and less behaviour discrepancies, so it may be sensible to pick one of the later versions, instead of 3.8. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
