On Wed, Sep 19, 2012 at 5:40 AM, Stephan Bergmann <sberg...@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 <mst...@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.ostrov...@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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice