On 7/4/21 3:01 pm, Sebastian Huber wrote: > On 06/04/2021 18:12, Gedare Bloom wrote: > >> On Mon, Apr 5, 2021 at 10:37 PM Sebastian Huber >> <sebastian.hu...@embedded-brains.de> wrote: >>> On 04/04/2021 22:18, Joel Sherrill wrote: >>> >>>> On Sun, Apr 4, 2021 at 2:25 PM Ida Delphine <idad...@gmail.com >>>> <mailto:idad...@gmail.com>> wrote: >>>> >>>> Hello, >>>> >>>> Please who are the possible mentors for this project? >>>> >>>> >>>> IMO this is a project which has a larger potential potential set of >>>> mentors than >>>> one focused on say a single board. >>>> >>>> >>>> On Sun, 4 Apr 2021, 3:32 am Ida Delphine, <idad...@gmail.com >>>> <mailto:idad...@gmail.com>> wrote: >>>> >>>> Regarding adding a script similar to linux/checkpatch.pl >>>> <http://checkpatch.pl> the criteria whether patches should >>>> need changes before being applied will be based on the output >>>> from running uncrustify right? >>>> >>>> >>>> Yes. Assuming we find a combination of uncrustify settings combined >>>> with changes to the RTEMS style and changes to uncrustify that put us >>>> in a place where we trust that the output wth the right settings >>>> matches our style. >>>> >>>> That is your goal. Find changes to the settlngs, uncrustify, and RTEMS >>>> code style where automated checking is possible. When you find a place >>>> where the coding style requires something uncrustify cannot currently >>>> do, the question is uncrustify changed or our coding style? >>>> >>>> Sebastian may have a list of some of those from his effort to create >>>> that configuration. But addressing the list of where the tooling and >>>> style guide do not align is a key part of your project. >>> I am not sure if tinkering code formatting tools to somehow produce the >>> RTEMS style is a suitable GSoC project. What has this to do with coding? >>> Also this task lingers around for years. Would it be a feasible task for >>> a student? >>> >> Setting the configuration is not a good task, but since we apparently >> can't find an out-of-the-box configuration, then there must be some >> coding that is required to make those style formatters able to support >> our style. (If not, then we should change our style later.) >> > Fixing in the pointer alignment in clang-format would help a bit to get > something closer to the current RTEMS style. We already identified this issue > in > 2018: > > https://lists.rtems.org/pipermail/devel/2018-December/024145.html > > The corresponding patch set is pending since 2016: > > https://reviews.llvm.org/D27651 > > Adding support for new options to clang-format has high barriers: > > https://lists.rtems.org/pipermail/devel/2018-December/024145.html > > It is probably easier to add new options to uncrustify. They already have more > than 700. > > The difficult parts in the RTEMS style are the alignment of variables and > parameters, the long functions > > return_type loooooooooooooooooooooooooooooonnnnnnnng( > > loooooooooooooooong looooooooooooonnnnnnnnng, > > a b > > ); > > and the long control statements > > if ( > > ... > > ) { > > ... block .. > > } > > Solving this with options is difficult. In some situations you need something > like this: if condition, then use rule of option A, else use rule of option B. > This rule selection may be done implicitly by the tool in a way you like it > or not. >
Would it be pragmatic to review these cases and change the standard? I understand the long history but as you point out we either invest in the tools to support the format, we change what we have or we manage it manually. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
