Here's a patch to add a .clang-format style file to the directory. Note
that this doesn't reformat the sources, but see the instructions in the
commit message to do that.
I dinf the results quite close to what we have. Please take a look and let
me know your opinon on the results.
Apart from that, there are several ways to enforce rules, for example using
git hooks that will run cheks before a submit or a push.
Other options are using a code review tool so that each patch is vetted
properly before being submitted, but that's more related to the discussion
about moving to gitlab/github.
Le mar. 7 juil. 2020 à 07:09, Werner LEMBERG <w...@gnu.org> a écrit :
>
> >> However, I've already invested a lot of time in writing ChangeLog
> >> entries...
> >
> > Would you consider dropping the ChangeLog entries.
>
> Basically, I don't object to that. However, experience has shown that
> people tend to write very sloppy git commit messages in general. The
> ChangeLog format enforces you to describe changes in a standardized
> way that I consider very helpful.
>
> > It is far simpler to rely on the git history for this, and just
> > enforcing that committer provide meaningful commit messages should
> > be enough?
>
> If we can do what Emacs does – namely git commit messages in ChangeLog
> style – I'm all for dropping direct ChangeLog entries.
>
> > Also, whenever you reformat some of the patches that are sent to
> > you, the original author has to resolve the conflicts manually, or
> > drop its own branch, which is not always practical (e.g. when there
> > are other work-in-progress commits/branches on top of the one that
> > was originally submitted).
>
> This is admittedly a problem.
>
> > Would you consider using clang-format to automate the formatting
> > task? I think we can get pretty close to the FreeType formatting
> > standard with a Clang style sheet. It won't be 100% the same, but
> > close enough to avoid repetitive work.
>
> If you can manage to write that, please do! Automatic formatting has
> definitely benefits. Honestly, I suggest that we get completely rid
> of the special FreeType formatting. For consistency I'm enforcing it
> on all pieces of code, but virtually all contributors have
> difficulties to follow the (unwritten) rules. Something like
>
> int main(int argc,
> char **argv)
> {
> FT_Error error;
> FT_Library library;
> FT_Face face;
> int i;
>
>
> error = FT_Init_FreeType(&library);
> if (error)
> {
> foobar();
> die("FT_Init_FreeType failed");
> }
>
> if (argc != 2)
> die("no font file argument given");
>
> ...
>
> looks nice IMHO – and is quite standard, AFAICS. Of course,
> vertical alignment like
>
> FT_Error error;
> FT_Library library;
> FT_Face face;
> int i;
>
> is quite nice, too, but I doubt that it can be really handled
> automatically.
>
> Whatever you come up with, please check whether our API documentation
> can be built correctly. Additionally, such a change should be
> introduced right after a release.
>
> > here's another patch that tries to fix this. Sorry about that.
> > Also Ben Wagner noticed me that some third-party code is using
> > FT_UNUSED(), so I've moved it back to public-macros.h to avoid
> > breaking this.
>
> Thanks, applied (with minor additions).
>
>
> Werner
>
From efa7fc4dcc0fe2b4a15cec1b04f45a71b99435cd Mon Sep 17 00:00:00 2001
From: David Turner <david.turner....@gmail.com>
Date: Fri, 1 May 2020 15:37:56 +0200
Subject: [build] Add .clang-format file
This file can be used to reformat FreeType sources and commits
using one of these methods:
- Direct formatting of a whole file:
clang-format -i path/to/file
For example, to reformat all sources at once:
echo builds/unix/ftconfig.h.in $(git ls-files *.[hc]) | xargs clang-format -i
- Only reformat the changed lines in the current work directoy:
git clang-format
The style settings in this file are very close to the FreeType
formatting style, with the following exceptions which are not supported
here:
- Mminimal 2-space margin on each non-empty line.
(no left margin instead).
- 2 empty lines between variable declarations and statements in C blocks.
(only 1 is kept).
{
int x = ...;
foo(x);
}
becomes
{
int x = ...;
foo(x);
}
- Aignment of declarations uses 2 spaces to separate types and variable
names (only 1 space is kept).
int x; => int x;
int y; int y;
- The start used for output parameters in function signature should be
near the variable name (always near the type).
void foo(int* input_ptr, int *output_ptr)
=> void foo(int* input_ptr, int* output_ptr)
---
.clang-format | 12 ++++++++++++
1 file changed, 12 insertions(+)
create mode 100644 .clang-format
diff --git a/.clang-format b/.clang-format
new file mode 100644
index 000000000..340a664a9
--- /dev/null
+++ b/.clang-format
@@ -0,0 +1,12 @@
+BasedOnStyle: Chromium
+AlignAfterOpenBracket: Align
+AlignConsecutiveMacros: true
+AlignConsecutiveAssignments: true
+AlignConsecutiveDeclarations: true
+AlignEscapedNewlines: true
+AlwaysBreakAfterReturnType: AllDefinitions
+BreakBeforeBraces: Allman
+ColumnLimit: 80
+DerivePointerAlignment: false
+PointerAlignment: Left
+SpacesInParentheses: true
--
2.20.1
