#3860 - GSoC enquiries

Sun Apr 4 20:18:19 UTC 2021

On Sun, Apr 4, 2021 at 2:25 PM Ida Delphine <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> wrote:
>
>> Regarding adding a script similar to linux/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.

--joel

>> On Sat, Apr 3, 2021 at 2:32 AM Gedare Bloom <gedare at rtems.org> wrote:
>>
>>> On Fri, Apr 2, 2021 at 6:09 PM Joel Sherrill <joel at rtems.org> wrote:
>>> >
>>> >
>>> >
>>> > On Fri, Apr 2, 2021, 6:59 PM Gedare Bloom <gedare at rtems.org> wrote:
>>> >>
>>> >> On Fri, Apr 2, 2021 at 4:48 PM Ida Delphine <idadelm at gmail.com>
>>> wrote:
>>> >> >
>>> >> > Hello,
>>> >> > Please can you help explain what you mean by Adding a "check-style"
>>> target to the RTEMS build system?
>>> >> > And how I could possibly go about this?
>>> >> >
>>> >> I don't know if this makes sense exactly to me.  When compiling RTEMS
>>> >> it could be nice to have an option to check the style rules for
>>> >> compliance. This would be something to integrate in the
>>> >> rtems.git/wscript file most likely, as part of the waf build system.
>>> >> However, since checking style does not generate a target file, I don't
>>> >> know that this really is suitable as a way to verify style rules. It
>>> >> may be suitable to add a standalone script in rtems-tools.git that can
>>> >> be run over the rtems.git that creates a report about style problems.
>>> >> Maybe, a way to configure it to ignore some files or to add exceptions
>>> >> to the style rules for certain cases then could be possible.
>>> >
>>> >
>>> > If you have a configuration that produces the code formatted as
>>> expected in certain directories, then if a change is made as part of normal
>>> development, running uncrustify will result in changes to the file needed.
>>> In a way the goal is to have a directory full of files that an RTEMS
>>> uncrustify configuration does not change.
>>> >
>>> > If you have a script that can do that manually then we can easily add
>>> an automated check somewhere in the process to ensure that directories that
>>> adhere to the style rules continue to adhere to them.
>>> >
>>> > One thing to keep in mind is that there there are places where
>>> uncrustify does not have the ability to format code the way RTEMS has
>>> historically done it. we want the rules to be as close as possible to the
>>> existing practice but we are willing to adjust practice if it allows the
>>> tool to produce formatted output we can trust.
>>> >
>>> Also on the table could be modifications to uncrustify.
>>>
>>> > On each point where this type of issue occurs, we'll have to have a
>>> discussion about our Style versus what tool supports. It's likely indicates
>>> we're doing something that's not common in the open source world.
>>> >
>>> > Once the delta between the output of uncrustify and the committed
>>> source is zero, running uncrustify should produce no changes. Anything
>>> uncrustify wants to change at that point would be a style violation and
>>> flagged. In a perfect world it would prevent you from committing.
>>> >
>>> >>
>>> >>
>>> >> I think focus on 1 and 3 is better as a way to start, and perhaps
>>> >> something like the above can be the phase 2 effort.
>>> >>
>>> >> Gedare
>>> >>
>>> >> > Cheers,
>>> >> > Ida
>>> >> >
>>> >> > On Mon, Mar 29, 2021 at 9:45 PM Gedare Bloom <gedare at rtems.org>
>>> wrote:
>>> >> >>
>>> >> >> On Mon, Mar 29, 2021 at 1:28 PM Ida Delphine <idadelm at gmail.com>
>>> wrote:
>>> >> >> >
>>> >> >> > Yes I have. But wondering how to run it with the given
>>> configuration I saw in this thread(
>>> https://lists.rtems.org/pipermail/devel/2020-October/062770.html).
>>> >> >> >
>>> >> >>
>>> >> >> If you download/copy the configuration into a cfg file, then you
>>> can
>>> >> >> use the examples from
>>> >> >> https://github.com/uncrustify/uncrustify#running-the-program and
>>> >> >> attempt to run it on some files within rtems.git/cpukit/score/src
>>> >> >> would be my suggestion.
>>> >> >>
>>> >> >> > On Mon, Mar 29, 2021 at 3:37 PM Gedare Bloom <gedare at rtems.org>
>>> wrote:
>>> >> >> >>
>>> >> >> >> Hi Ida,
>>> >> >> >>
>>> >> >> >> On Mon, Mar 29, 2021 at 7:36 AM Ida Delphine <idadelm at gmail.com>
>>> wrote:
>>> >> >> >> >
>>> >> >> >> > Hello,
>>> >> >> >> > Please do you mind telling me how to run uncrustify with the
>>> given configuration with any sample file?
>>> >> >> >>
>>> >> >> >> What have you tried? Any directions followed/attempted or notes
>>> that
>>> >> >> >> you have taken would be helpful.
>>> >> >> >>
>>> >> >> >> I guess all the info that you should need is in Uncrustify's
>>> readme
>>> >> >> >> file. https://github.com/uncrustify/uncrustify
>>> >> >> >>
>>> >> >> >> Did you successfully compile uncrustify tool?
>>> >> >> >>
>>> >> >> >> > I'm a bit stuck.
>>> >> >> >> >
>>> >> >> >> > Thanks,
>>> >> >> >> > Ida.
>>> >> >> >> >
>>> >> >> >> > On Wed, Mar 17, 2021 at 10:34 PM Gedare Bloom <
>>> gedare at rtems.org> wrote:
>>> >> >> >> >>
>>> >> >> >> >> On Wed, Mar 17, 2021 at 2:28 PM Ida Delphine <
>>> idadelm at gmail.com> wrote:
>>> >> >> >> >> >
>>> >> >> >> >> > Hello,
>>> >> >> >> >> > So I have gone through this configuration file and I think
>>> I'm getting it. However I'm a bit lost in the reading the messages in the
>>> thread. Do you mind explaining? Or we can start talking about a way forward.
>>> >> >> >> >> > Also can you help me with some steps on how to test this
>>> by myself if possible?
>>> >> >> >> >> >
>>> >> >> >> >>
>>> >> >> >> >> It may be easier if you go "up" a level to see the full
>>> thread
>>> >> >> >> >> context:
>>> https://lists.rtems.org/pipermail/devel/2020-October/thread.html#62769
>>> >> >> >> >> Then you can go through the messages non-linearly. Right
>>> now, the
>>> >> >> >> >> basic idea is to follow the steps outlined in the open
>>> project ticket.
>>> >> >> >> >> I think Christian has summarized it nicely in his recent
>>> email [1]: "I
>>> >> >> >> >> think the contributions from this project that would add
>>> value would
>>> >> >> >> >> be:
>>> >> >> >> >> 1. Finding a tool and a configuration that can do an RTEMS
>>> style or an
>>> >> >> >> >> acceptable close one.
>>> >> >> >> >> 2. Adding a "check-style" target to our build system.
>>> >> >> >> >> 3. Maybe add some kind of script similar to Linux "
>>> checkpatch.pl" that
>>> >> >> >> >> could check whether patches would need changes _before_ they
>>> are
>>> >> >> >> >> applied.
>>> >> >> >> >> "
>>> >> >> >> >>
>>> >> >> >> >> The proposal preparation phase should work through
>>> identifying the
>>> >> >> >> >> options and pros/cons for different tools while preparing a
>>> plan for
>>> >> >> >> >> how to integrate style checks in 2, 3 and thinking through
>>> the coding
>>> >> >> >> >> tasks for the summer.
>>> >> >> >> >>
>>> >> >> >> >> Getting the style checking tool's configuration to match
>>> with the
>>> >> >> >> >> RTEMS style will be some effort, and testing it out and
>>> submitting
>>> >> >> >> >> some patches based on it could be a good proposal activity
>>> also to
>>> >> >> >> >> build some confidence about the tools that will be used.
>>> >> >> >> >>
>>> >> >> >> >> We also have some Python style guidelines that might be worth
>>> >> >> >> >> addressing. Those are harder maybe, since the style
>>> refactoring might
>>> >> >> >> >> be challenging to review for correctness.
>>> >> >> >> >>
>>> >> >> >> >> For getting started, I would recommend that you try running
>>> uncrustify
>>> >> >> >> >> with the given configuration on some files in RTEMS, see
>>> what it
>>> >> >> >> >> results in. Play around.
>>> >> >> >> >>
>>> >> >> >> >> [1]
>>> https://lists.rtems.org/pipermail/devel/2021-March/065547.html
>>> >> >> >> >>
>>> >> >> >> >> -Gedare
>>> >> >> >> >>
>>> >> >> >> >> > Thanks,
>>> >> >> >> >> > Ida
>>> >> >> >> >> >
>>> >> >> >> >> > On Mon, Mar 15, 2021 at 9:39 PM Gedare Bloom <
>>> gedare at rtems.org> wrote:
>>> >> >> >> >> >>
>>> >> >> >> >> >> See the related thread, and we'll have to discuss how to
>>> move forward.
>>> >> >> >> >> >> The existing approach provides an uncrustify script:
>>> >> >> >> >> >>
>>> https://lists.rtems.org/pipermail/devel/2020-October/062769.html
>>> >> >> >> >> >>
>>> >> >> >> >> >>
>>> >> >> >> >> >> On Sun, Mar 14, 2021 at 9:47 PM Ida Delphine <
>>> idadelm at gmail.com> wrote:
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > Hello everyone,
>>> >> >> >> >> >> > This ticket(https://devel.rtems.org/ticket/3860) was
>>> proposed to me and I'm interested in it for GSoC.
>>> >> >> >> >> >> > The first task there is to find a code checker or
>>> formater that can produce results that match the RTEMS coding conventions.
>>> It also made mention some tools have been discussed in the past. Please I
>>> will love suggestions on possible tools I could use to achieve this.
>>> >> >> >> >> >> >
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > Cheers,
>>> >> >> >> >> >> > Ida.
>>> >> >> >> >> >> > _______________________________________________
>>> >> >> >> >> >> > devel mailing list
>>> >> >> >> >> >> > devel at rtems.org
>>> >> >> >> >> >> > http://lists.rtems.org/mailman/listinfo/devel
>>> >> _______________________________________________
>>> >> devel mailing list
>>> >> devel at rtems.org
>>> >> http://lists.rtems.org/mailman/listinfo/devel
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210404/48ed8e17/attachment-0001.html>