Hi William,

On Sat, May 09, 2020 at 04:20:44PM +0200, William Dauchy wrote:
> >   - 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
> projetcs.

It is maintained out of tree and even used by a few other projects.
If you need it it's here:


Be careful however, haproxy uses v6 and modified it a little bit. The
master there is the start of v7 but most of the ongoing work in another
branch because I was still not 100% convinced by the design choice.

> >   - 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.

I agree. Also it happens that by laziness we sometimes have to add a
function and only the types/ variant exists so the addition finishes
by being added to types and it ultimately causes trouble (see global.h
for example).

> 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 agree. Similarly that's something that's been done wrong by laziness
and that has been complicating the share of some code parts. We've done
this as well is standalone code (such as H2 etc) but ultimately it turned
out that in order to exploit some stats or anything else, finally we'd
have liked to see these ones outside. Also keeping defines local to the
C file tends to encourage using short, possibly conflicting names, which
occasionally cause trouble when including other files there.

> > 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.

Exactly! And there are a few past examples of minor tweaking of a few
#include entries just to quickly work around the issue by finding a
working combination. But that's not a future-proof approach.

> I also have the frustation to not be 100%
> sure I did not forget some includes which are naturally included by
> other dependencies,

It's less of a problem. We consider that a file should include the files
that it needs. Often if you forget some it continues to work because most
of the low-level includes are used everywhere and already included where
the other ones are used. So you don't really risk failing in this case.
What sometimes happens is that someone cleans a few unneeded includes and
discovers an unrelated breakage, but that's quickly fixed then.

> or worse, extra includes which are not needed
> anymore because code was removed; anyway that's more inherent to the
> language itself.

It's not really inherent to the language, rather to the common usage.
But similarly it's not a big deal when this happens.

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

Many thanks for sharing this. It's not a matter of counting much or not.
In fact there are two aspects that count a lot to me :

  - not needlessly wasting the time of those spending their whole day
    on the code. If changes cause a permanent waste of 1 hour per day
    it's not acceptable; conversely I'm willing to invest efforts to
    save a few minutes per day to all developers.

  - easing first approach to new contributors. The current situation
    is not good and when you see that those spending their whole time
    on it get caught, you easily understand the mess it can be for a
    newcomer who will first believe he did something wrong.

The rest is not much important. Long-time developers will quickly get
their fingers trained to opening new file names, and if it takes me
1-2 days to rename and move everything, it's worth it.


Reply via email to