Re: [RFC] [WIP] incorporate picotcp into barebox: a small demo

[Daniele Lacamera <daniele.lacamera@tass.be>]

Antony, thank you very much for the comments and the bug reports on
our github. See comments below.

On Tue, May 27, 2014 at 4:04 PM, Antony Pavlov <antonynpavlov@gmail.com> wrote:
> On Tue, 27 May 2014 11:46:29 +0200
> Daniele Lacamera <daniele.lacamera@tass.be> wrote:
>
>
> linux kernel and barebox use not so much #ifdef's because they use
> they use IS_ENABLED() macro with just the same result.
[...]
> so the code under IS_ENABLED() is always parsed by C compiler;
> if there is an syntax error in this code then the compilation will be stopped.

We will discuss this and see if it is applicable for PicoTCP. The
macro you are suggesting is indeed not increasing code size, but our
static checkers might be not so happy about all this preprocessor
machinery.

>
> $ gcc --version
> gcc (Debian 4.8.3-1) 4.8.3
>
> Here is my 'make -s' output for sandbox barebox:
>
[cut]

Thank You!! This *IS* very helpful input. We are going to add more -W
flags and quickly fix these warnings.

> But in linux kernel, barebox, qemu and IMHO many other projects
> there are:
>
>   * CODING_STYLE documentation file;
>   * scripts/checkpatch.pl
>

All good points. Being a kernel developer myself, I know the
checkpatch.pl approach, and indeed it is a good thing to distribute
coding rules if you accept contributions. Except it will never apply
to us, because:

- We have our company internal coding style which we apply to all our
projects and we don't feel the need to distribute externally (keep in
mind that we never planned to accept external contributions). Instead,
the repository contains the uncrustify configuration file, which is
pretty much self-explanatory.
- A few of us are checking every single commit, and running uncrustify
every now and then. We are comfortable with this approach
- Linux coding rules are generally recognized as possibly not the best
in the world. I especially dislike tabs.
- commit hooks are tedious

I am afraid we are not going to change our formatting style or policy,
but thanks anyway for the suggestions!

/d

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox