kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

John,

On 5/6/2019 8:11 AM, John Beard wrote:
> On 03/05/2019 19:28, Wayne Stambaugh wrote:
>>
>> I'm guessing John used a later version of clang-format when he wrote the
>> commit hooks.  John, any ideas how to fix this or do we force devs to
>> use clang-format > 3.8?
> 
> I'm on Arch, so I have quite recent clang-format (8.0.0). This
> particular option has always been in the _clang-format, and seems the
> config was introduced in clang-format 3.9.
> 
> I don't really have any great idea to fix this in general. I think the
> options are:
> 
> * Tell people to use 3.9 or later (actually I don't know what options we
> have need what versions). Most distros will allow people to install
> newer toolchains (sometimes need to enable the updates/backports repos).
> I think clang 4 is available in Mint 18/Xenial, and 5 and 6 are in
> Xenial-updates.
> 
> * Provide multiple style files, suitable for older clangs. Then the git
> hook can feed the right one to clang-format. In this case, you might
> find formatting differences if people use older clangs.
> 
> * Remove any options that don't suit clang 3.8 (our de facto minimum
> version) and deal with the misformattings:
> 
> In this case: formatting clang-format <= 3.8 (BreakStringLiteral not
> available, so "default", which is "true"):
> 
>     std::string var =
>             "Lorem ipsum dolor sit amet, consectetur adipiscing elit, "
>             "sed do eiusmod tempor incididunt ut labore et dolore magna "
>             "aliqua";
> 
> Current _clang-format (BreakStringLiteral=false) with clang-format >= 3.9:
> 
>     std::string var =
>             "Lorem ipsum dolor sit amet, consectetur adipiscing elit,
> sed do eiusmod tempor incididunt ut labore et dolore magna aliqua";
> 
> I suspect this happens little enough that we can deal with it in any
> case. People always need to be aware that you cannot blindly apply the
> formatter anyway. `git add -p` is the way to selectively apply
> formatting changes.
> 
> @Reese, could you give it a go with clang-4 and see if there are any
> more broken options?
> 
> @Wayne, any preference for how we deal with it?

I'm fine with asking users to update clang-format.  Even if they are not
interested updating, breaking long strings is fairly uncommon and we can
just ask patch submitters to break the string as needed.

Wayne

> 
> Cheers,
> 
> John
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp