https://ftp.rtems.org/pub/rtems/people/amar/files/rtems.uncrustify
On Fri, Sep 11, 2020 at 11:46 AM Joel Sherrill <j...@rtems.org> wrote: > > > On Fri, Sep 11, 2020 at 11:06 AM Gedare Bloom <ged...@rtems.org> wrote: > >> On Fri, Sep 11, 2020 at 1:41 AM Sebastian Huber >> <sebastian.hu...@embedded-brains.de> wrote: >> > >> > On 10/09/2020 17:32, Joel Sherrill wrote: >> > >> > > >> > > >> > > On Thu, Sep 10, 2020 at 10:24 AM Gedare Bloom <ged...@rtems.org >> > > <mailto:ged...@rtems.org>> wrote: >> > > >> > > On Mon, Sep 7, 2020 at 12:06 AM Sebastian Huber >> > > <sebastian.hu...@embedded-brains.de >> > > <mailto:sebastian.hu...@embedded-brains.de>> wrote: >> > > > >> > > > Hello, >> > > > >> > > > I think we waste too much time to address coding style issues on >> > > newly >> > > > contributed code, for example GSoC. I don't know a source code >> > > > formatting tool which supports the RTEMS coding style and I >> > > think it is >> > > > not worth the time to write and maintain such a tool >> > > specifically for >> > > > RTEMS. Why don't we simply allow an alternative coding style >> > > which has a >> > > > good code formatter for new source files? I don't propose to >> > > reformat >> > > > the existing files. >> > > > >> > > > I would simply pick up one of the standard styles supported by >> > > > clang-format and declare it as an acceptable coding style for >> RTEMS. >> > > >> > > >> > > I am not willing to blanket accept another project's coding style. >> > > >> > > I am willing to accept a configuration for a tool that is close to our >> > > style and >> > > make compromises on specific points. >> > >> > We had a student to figure this out for clang-format some time ago: >> > >> > https://lists.rtems.org/pipermail/devel/2019-February/024912.html >> > >> > We could also have a look at uncrustify: >> > >> > https://github.com/uncrustify/uncrustify >> > >> > It seems to be still actively maintained on Github. >> > >> > > >> > > I also think when doing this we should consider things that we do that >> > > we have since learned safety standards don't like such as single >> statement >> > > if's without braces. I think we should have braces now. >> > I think uncrustify had options to do this. I am not sure if clang-format >> > can do this. >> > > >> > > This is best viewed as an opportunity to improve but comes with >> changes >> > > since I don't think any of us wants to add a few more configuration >> > > options >> > > to any formatter. Although if we get close, I can see adding those as >> open >> > > projects if someone is interested. >> > Good, I think we should have a look at uncrustify. The RTEMS coding >> > style is too exotic for clang-format. >> >> Let's start with uncrustify. The github looks solid with >> cross-platform compatibility claims (*nix, Windows, OSX). >> >> I know that there was an RTEMS style script generated by Sebastian >> some time ago. We had it on the wiki forever, but now it is a broken >> link in the docs >> >> https://devel.rtems.org/attachment/wiki/Developer/Coding/Conventions/rtems.uncrustify >> >> from >> https://docs.rtems.org/branches/master/eng/coding-conventions.html#tools >> >> So we'll need to revive that first, and iterate. >> > > Amar has backups of the old wiki based on wikipedia and I think he can > access it easily. > > --joel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
