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