I meant to write about intra-, not inter-, module header includes (of
headers also delivered to be inter-module include-able from later
modules), sorry if that confused anybody.
Stephan Bergmann wrote:
Hi all,
<http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=SRC680%2Fhedaburemove01>
delivered us from hedabu.
However, the way this was done lead to the module-local inc/$PRJNAME
(where PRJNAME is the module name) to be added to the C/C++ compiler
include search path in every module (solenv/inc/target.mk:1.194).
That triggered <http://www.openoffice.org/issues/show_bug.cgi?id=76340>,
where obscure constellations in sal prohibit adding sal/inc/sal to the
C/C++ compiler include search path in sal. The ad-hoc fix was to not
add inc/$PRJNAME if $PRJNAME == sal (solenv/inc/target.mk:1.195).
That in turn caused Ause and me to reflect on the overall fidelity of
generally adding the module-local inc/$PRJNAME to the C/C++ compiler
include search path. What is the state the code should ideally be in?
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).
Others?
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
