On 03/11/2013 01:24 PM, Andrew Stitcher wrote:
On Mon, 2013-03-11 at 12:51 -0400, Alan Conway wrote:
On 03/08/2013 01:07 PM, Cliff Jansen wrote:
Not that this speaks directly to the issue of instant deletion versus
a more dignified old-folks home retirement, but I would point out that
CMake is the sole build mechanism for AMQP 1.0 support in C/C++. You
can't avoid it going forward for at least part of your build.
Also since a lot of the test infrastructure is tied to the build
system, there will be an awful lot of holes showing up fast in the
automake side.
Finally, the effort to allow the automake side to continue to build
(if only to a limping state) may consist of cruel and unusual
punishment for an unlucky developer who is trying to add useful new
features (async store perchance?).
Fraser makes a fail point about the deprecation not being obvious since the
instructions etc. still say to use automake.
Here's a softer proposal: we fix configure to fail by default and print a
deprecation message, then add an option
--you-really-should-use-clearmake-but-ok-if-you-insist=yes for those who want to
continue with automake. We fix the instructions to direct people to clearmake,
we keep automake working for this release, but ignore it after that. We can
remove it completely at the next release.
I agree with this approach, but I suggest that we prioritise getting the
cmake build instructions into The 0.22 Readme, and suggest in the
release notes that people prefer to use cmake to build rather than
autotools. That way we'll get a flood of bug reports in the 0.22 time
frame and fix them for 0.24 when we get serious!
Just to be clear: do you agree with having configure fail with a deprecation
warning unless --use-deprecated=yes? We do want to update the doc & release
notes but those are easily missed by people who are already used to building
Qpid. A build failure is hard to miss.
Cheers,
Alan.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
