On Sat, May 09, 2020 at 12:48:30PM +0200, Willy Tarreau wrote:
> I prefer to warn, this is long and only of interest for those who code,
> so don't force yourself to digest this if not necessary :-)

nice summary as always!

> In the end I think that would leave us more or less with this:
>   - creation of a new "base" directory to put the few files that must not
>     depend on anything else and which are solely used to ease portability
>     (compat, defaults, compiler as of today).
>   - move of ebtree/* into import/

I must admit on this specific ebtree one, I always asked myself why this
was not maintained out-of-tree. I guess that's mainly for simplicity and
historical reasons. I also don't know whether it is already maintained
elsewhere but I guess this could be or could have been used in other

>   - creation of haproxy/ to move everything related to our internal
>     architecture there, with a second file when static functions are
>     needed.
>   - kill types/ and proto/

For having been confronted to the situation very recently it's true
that's is not necessary natural to always ask yourself what is a type,
what is a proto so I agree it would probably make the things easier to
think about / search even though files would be bigger.
Even in code reading situations it will be easier to find the
information at the same place I believe.

Among that they are sometimes situations where defines/types/protos are
done within the .c file because it is only used there. In my very own
opinion I would enforce to move them in .h files. While reading the code
that's where you would expect to find them, but also when you suddenly
need them in another .c file, it would avoid to reorganise things. I
might be completely wrong here though.

> I'm interested in any opinion on the subject, especially from those who
> touch this code all day, but also from those who touch is once in a while
> and who experienced difficulties finding their way through this.

So I'm not a daily user of those files, but I believe it is often
annoying to land in a circular dependency issue; at some point you
somehow find a solution, and once it compiles without warning, just hope
to not touch them anymore. I also have the frustation to not be 100%
sure I did not forget some includes which are naturally included by
other dependencies, or worse, extra includes which are not needed
anymore because code was removed; anyway that's more inherent to the
language itself.

Well this was my two cents short opinion even though I do not count


Reply via email to