On Tue, 2011-03-22 at 14:35 -0400, Matthew Barnes wrote:
For 3.1, I would like to provide a top-level header file for each of the
libraries in E-D-S and deprecate including individual header files. The
benefits should be clear by now: more flexibility to change or rearrange
header files
On Tue, 2011-03-22 at 14:35 -0400, Matthew Barnes wrote:
For 3.1, I would like to provide a top-level header file for each of the
libraries in E-D-S and deprecate including individual header files. The
benefits should be clear by now: more flexibility to change or rearrange
header files
On Di, 2011-03-22 at 14:35 -0400, Matthew Barnes wrote:
For 3.1, I would like to provide a top-level header file for each of the
libraries in E-D-S and deprecate including individual header files. The
benefits should be clear by now: more flexibility to change or rearrange
header files
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
On Mi, 2011-03-23 at 09:05 -0400, Matthew Barnes wrote:
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:
On Wed, 2011-03-23 at 15:52 +0100, Patrick Ohly wrote:
I thought that this break would go into 3.0 (see my initial reply). So
if 3.1 requires changes anyway, then sure, go ahead and break it some
more ;-)
Oh, I missed that in your first reply. Sorry.
That was the plan originally, but
