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.
_______________________________________________
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
