Re: [Evolution-hackers] Front-end header files for E-D-S libraries

[Matthew Barnes <mbarnes redhat com>]

On Wed, 2011-03-23 at 13:42 +0100, Patrick Ohly wrote:
> How much of a problem is that in practice?

It's getting to be a problem.  Seemingly innocent changes to header
files break builds in unexpected ways.  Here's a common scenario:

   - Header file <foo.h> includes <bar.h>.

   - A client program includes <foo.h> and uses things defined there.

   - Later, the client program starts using things defined in <bar.h>,
     but forgets to include it explicitly.  It just happens to work
     because <foo.h> includes it.

   - Down the road, <foo.h> no longer includes <bar.h> for some reason
     or another.  Maybe to resolve a cyclic dependency between the two.

   - The client program now fails to build, because <bar.h> was never
     explicitly included.

Forcing the client program to include a front-end header file for the
library, which itself includes both <foo.h> and <bar.h>, avoids this
problem.  This is why most other libraries already do it this way.

Another scenario is when a pair of header/body files is getting to be
overly bloated and complicated and developers would like to divide it
into smaller files so it's easier to understand and maintain.  Without a
front-end header file for the library we don't have the flexibility to
do this with without breaking the public API.


> Is there a chance to add the headers to 3.0 before it gets released?

It's too late for 3.0.0.  I can add it for 3.0.1 sans the preprocessor
warnings if that would help.