On Thu, 19 Mar 2020 16:56:04 +0000
Fil Lupin <[email protected]> wrote:

> Hi,
Hi,

> I think some tools could be useful to automatize some tests, in order
> to focus on complex checkings. These tools exists for several
> languages (
> https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis#C,_C++)
> :

> - python : I realize flake8 is MIT (sorry),
The MIT license is free software.

For C, in libsamsung-ipc at least, we could start by converting the code
to use Linux's style and use and/or adapt their scripts to check the
patches. Other projects like u-boot also use similar scripts.

Linux's style is supported by Emacs and it's probably supported by many
other text editors as well.

The advantage of this process is that it's semi automatic: if the
checkpatch errors don't make sense, you can ignore them, so it's not
an intrusive process. However you need to remember to do it each time
you send a patch.

> They can be used using a prehook added by each user (I use hg but git
> allows this behaviour also).
I'm not sure yet about that. It's not very practical to have a hook run
each time you amend a commit for instance. 

Coreboot had similar practices in places, and I ended up having to
workaround it by using a dedicated git repository to send the patches.

Without that you have to wait for a significantly long time each time
you need to amend a commit. You might also need to work on or even push
non-clean code in your own user repositories for instance, or even send
an RFC patch that doesn't compile and is very dirty.

> or even added as a continuous integration if the project decide it's
> worth it.
It could be interesting to do, especially if we find a way to do it in
a way that is efficient and suits Replicant's needs.

For C we could also step up the requirements by testing with compilers
settings that are more strict, while at the same time having it be not
intrusive and making sure that the people working on the code
(including for a single quick patch) know how to disable that.

Here's an example of issues that could arise if the continuous
integration is not very efficient: https://lwn.net/Articles/813767/

Another issue would be to have the continuous integration slow down
significantly the development. For instance if you need to wait many
hours before sending a patch, it's probably not that great for the
people wanting to send one quick patch.

I'll look into more details in the comments for the other patches I
sent and into the tools.

Denis.

Attachment: pgpVfrRctFXIL.pgp
Description: OpenPGP digital signature

_______________________________________________
Replicant mailing list
[email protected]
https://lists.osuosl.org/mailman/listinfo/replicant

Reply via email to