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.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@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/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
