taler
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Taler] Coding style clang-format


From: ng0
Subject: Re: [Taler] Coding style clang-format
Date: Wed, 24 Apr 2019 12:14:57 +0000

If you apply this wholesale for git.taler.net,
make sure that you do NOT apply this for gnurl.
I generally try to avoid having unnecessary work
with gnurl. Code reformating would fall under
"unnecessary work".

While I do this for other forks I maintain myself,
gnurl is not like those forks (which were initiated
for other reasons and don't have upstreams anymore/
not as active as curl).

On the whole topic of clang-format:
I'm torn between liking it and not liking it.
The argument Martin brought up that you don't really require llvm
seems not to be true - you still need to compile llvm to get a
usable clang-format, at least reading into the build system of it.
For developers this overhead is okay, but at the same time it's
annoying that you might have to build llvm until a new release is
out. 

Christian Grothoff transcribed 3.4K bytes:
> Ah, I thought you were talking about less crazy single-file imports
> (like say gnunet/src/util/getopt.c from the GNU copylib).  So sure, for
> those "big" third party imports we'll need more narrow rules on which
> files/directories formatting is to be enforced.
> 
> On 4/18/19 2:53 PM, Florian Dold wrote:
> > We have *tons* of third party code in akono (Android/Kotlin bindings for
> > node.js, part of the PF project), as well as the repository that is used
> > to build the GNU Taler wallet for wasm.
> > 
> > Putting /* clang-format off */ on top of every source file does not
> > quite work for these.
> > 
> > - Florian
> > 
> > On 4/18/19 2:48 PM, Christian Grothoff wrote:
> >> On 4/18/19 2:37 PM, Florian Dold wrote:
> >>> I think it's a great idea!  Since clang-format can reformat all of
> >>> GNUnet in <1s on my laptop, it should be fast enough to run as part of
> >>> every commit.
> >>>
> >>> However, there must be an option to enable/disable this on a
> >>> per-repository or even per-path basis, since we do not want to re-format
> >>> third party code that is checked into our repos.
> >>
> >> Well, I generally would prefer to avoid checking in third party code
> >> into our repos, but you are of course right that this does sometimes
> >> happen for good reasons.
> >>
> >> But in that case, I think simply adding a /* clang-format off */ on top
> >> of the 3rd party code should do.  And of course the rule should only
> >> apply to C and H files in src/.
> >>
> > 
> 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]