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

[Stephan Bergmann]

On 09/18/2012 12:14 AM, Norbert Thiebaud wrote:
> On Mon, Sep 17, 2012 at 11:48 AM, Stephan Bergmann <sbergman at redhat.com> wrote:
>> But why should anybody coming to this project not be able to expect the
>> assert mechanism to be working as advertised by the Standard?
>
> in order to have such behavior, he would have to add another  #include
> <cassert> somewhere...
> This is a matter, then, of code review and checking with him why he
> really need that...
> as long as this is done in a source code... after the includes for
> that source code, the fiddling would have limited scope (only that
> particular source)
> and quite frankly It is very unlikely that that would be a legitimate case.

Oh, by "working as advertised" I was relating to something much simpler 
than being interested in fiddling with NDEBUG settings in the code, 
namely that adding usage of assert() to some file requires adding 
#include <assert.h> too.  (Which would work differently for LO, where 
one would be required /not/ to add #include <assert.h>.)

> 2/ the benefit of having a standard product-wise include. that is
> included in every source (and never in a header)... iow a sal/config.h
> but for libreoffice, not sal, and actually enforced with stricter
> semantics..
[...]
> for 2/
> I propose to create a file 'lo.h', in solenv/inc/ for now... and start
> to bring all source code in conformance... I would have that lo.h
> include sal/config.h and other sal+osl+rtl header that are extremely
> commons (like ustring.hxx). and start to clean-up such include in the
> rest of the code. note: my priority is to bring some order to the
> includes, performance is not the main motivation).
> Having such a header and its use actually enforced give a nice
> platform to do pretty fancy stuff, and to avoid the all to common
> re-invention of the wheel wrt to convenience macros.
> Yes it is a lot of grease-monkey work... but hey I'm used to that...
> and I don't mind.. it's like doing Sudoku to me :-)

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.

How would you have "its use actually enforced"?  The possibility "to do 
pretty fancy stuff" that requires a header that is always included first 
is already there with sal/config.h.  How "re-invention of the wheel wrt 
to convenience macros" would be addressed with such a header I do not 
see; I think it is more important to make people aware of what is 
already available than whether to include lo.h or a specific header for 
a given functionality.

Stephan