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 projetcs. > - 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 much. -- William
