#3860 - GSoC enquiries

[Chris Johns]

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.huber at embedded-brains.de>  wrote:
>>> On 04/04/2021 22:18, Joel Sherrill wrote:
>>>
>>>> On Sun, Apr 4, 2021 at 2:25 PM Ida Delphine <idadelm at gmail.com
>>>> <mailto:idadelm at 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, <idadelm at gmail.com
>>>>      <mailto:idadelm at 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