Mathias Bauer wrote:
Stephan Bergmann wrote:
A Should inter-module includes generally be "module/header" instead of
just "header"? Then the current hedaburemove01 changes would be a
pragmatic hack---instead of changing tons of include lines in tons of
source files, change a single line that magically extends the search
path wherever necessary (and also where not necessary). If this is the
ideal state, the drawback of the hedaburemove01 changes is that they
potentially move us further away from that state---new code can
introduce sloppy includes of just "header" that should be
"module/header", even in modules where this would have been caught before.
B Or should inter-module includes generally be just "header" instead of
"module/header"? Then the current hedaburemove01 changes would be sound
(and the modules that until now only allowed "module/header" should
ideally be cleaned up).
C Or should we allow inter-module includes to be just "header" and
"module/header" higgledy-piggledy?
In my opinion A should be the ideal state to aim for: It makes more
information explicit than B, so it should be more helpful to code
readers, and it should be less error prone (witness issue 76340).
In fact the current state is "C"
You misunderstand me. The current situation is as follows (correct me
if I am wrong):
- Any given delivered header, in the module from which it is delivered,
is either consistently included as "module/header" (the "UNO" style,
used e.g. in salhelper) or as "header" (the "appliations" style, used
e.g. in tools). (Any given delivered header, in other modules than the
one from which it is delivered, is always included as "module/header".)
- Any given header that is not delivered is consistently included in
some form ("header", "module/header", "../header", etc.) in the
respective module.
(So, yes, there is some form of higgledy-piggledy already, caused by the
difference between delivered and non-delivered headers. I guess that is
inevitable, and, used judiciously, could even be a source of helpful
information. For example, stick to a discipline where (a) exported (aka
delivered) headers are stored in <module>/inc/<module> and included as
"module/header", (b) module-wide headers are stored in
<module>/source/inc and are included as "header", (c) directory-local
headers are stored in <module>/source/<whatever> next to the cxx files
and are included as "header", (d) imported headers from other modules
are included as "module/header", and (e) system headers are included as
<header>.)
With C, the first part would change to "Any given delivered header, in
the module from which it is delivered, can be inconsistently included as
either "module/header" or "header" in different places." That's what I
meant with "higgledy-piggledy."
-Stephan
> and if we don't go for "B" it will stay
so as we still include all headers as "header" if they are not exported
(at least in most projects). These files reside either in the source
directories or in other include directories of the project(not in the
"inc" directory in the project root), like sw/source/ui/inc.
A script doing the conversion for includes of exported headers following
solution "A" would need to lookup headers before it can decide whether
the include statement needs to be changed or not. And the result would
still be "higgledly-piggledly".
Heading for solution "B" would need a less sophisticated script. And it
would be less work as a change according to "A" would affect the bigger
and more frequently edited modules and so create more resync surprises
for existing CWSs.
Ciao,
Mathias
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
