Re: sal/config.g sal/types.h and sal/osl/rtl includes in general

On Wed, Sep 19, 2012 at 5:40 AM, Stephan Bergmann <sbergman@redhat.com> wrote:
> I'm not sure such a lo.h combining inclusion of multiple other header files
> would be a good idea.  With the constant flux across our code base, I think
> aiming at precise, minimal includes is a better approach, as it helps
> achieving minimal rebuilds.

The current approach does nothing for that.
The current approach to include has nothing to minimal rebuild, it has
to do with random decisions and method to achieve a build at all when
new code is added.

> How would you have "its use actually enforced"?
because if sal/types.h is included only via lo.h (which is very easy
to insure with a simple grep)
then 99.9% of the source we have would not build...

>  The possibility "to do
> pretty fancy stuff" that requires a header that is always included first is
> already there with sal/config.h.

No it is not.
sal/config.h get included yes... eventually... but certainly not
guaranteed as a 'first' include...

and furthermore. sal/config.h is part of URE... which for better of
worse we pretend that there is other user than libreoffice... so it is
surely not the place to put fancy stuff that only serve to build
libreoffice...
in fact all my talk about lo.h would purposefully avoid messing with
anything that is delivered in the SDK.

>  How "re-invention of the wheel wrt to
> convenience macros" would be addressed with such a header I do not see;

all my own real-life every source start with

#include "core.h"
#define MODULE_NAME <module_name>
#include "modules.h"

the #define in the middle allow a bunch of things to be per-module,
including tracing/logging, unique error-codes, unique message type
etc..
That is just on example or one way to use that kind of regularity.

On Wed, Sep 19, 2012 at 5:49 AM, Michael Stahl <mstahl@redhat.com> wrote:
> i fully agree with that; these "convenience headers" tend to become a
> pain in the long run, and back in the day i've heard regrets from a few
> developers at Sun about the ones they've added themselves and how they
> wish they never had done that :)

I'm not talking about header that include header for the sake of it.
like a dummy header just tot include a dozen of commonly include
headers...
not what I have seen at time is including a header of an unrelated
object, just because it itself pulled in all the include that one
needed.

The main reason lo.h include anything to start with is to make sure it
is not forgotten. if lo.h is the only thing that provide include
<sal/types.h> for instance... then You can be sure that 99.9% of you
source won't forget it. and the 0.1% are to be investigated as to
'what the heck are they doing that doe not need sal at all.

On Wed, Sep 19, 2012 at 8:27 AM,  <d.ostrovsky@idaia.de> wrote:
> Was spending hours (!) yesterday during rebuilds with total ccache misses
> because of recent header changes.

this has nothing to do with it.
sal/inc/* have been impacted by 318 changes since the beginning of LO,
154 time this year. it happens...
so even if I put the whole sal/inc/* in lo.h that would still only
havve triggered 154 full rebuild... with what I am thinking of putting
in lo.h at this point,  83 commits out of these 154 would have
triggered a full rebuild... most of them already did 1 touched
sal/config 14 touched sal/types.h, 37 ustring.hxx each of these
already trigger a full rebuild.


and talking about the goal of 'minimal' include, and the impact of
things on 'novices'

given a random class/enum/struct/union/typedef/macro name what is the
name of the header you should include ?
git it a try:

for SfxSimpleHint  you need to include ... ?
for ColorMask you need to include ?
for GRAPHICDRAWMODE_WATERMARK you need to include ?

So there is no automatic way to verify that an include set is
'minimal', but there isn't even a way to do that with eyeballing...
short of parsing every lexeme of the source, and groking where they
come from, and verify that we do have the include for it, making that
include as useful, and then deleting any include that are not 'used'.
hey... maybe an idea for a clang plugin... :-)  given a compile,
produce the list of header that are really used directly from that
source (bonus point , generate a list fo each header recursively based
on what it intrinsically need )

Norbert