#3860 - GSoC enquiries

[Sebastian Huber]

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.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/