On 03/15/2013 10:35 AM, Robbie Gemmell wrote:
Its quicker for me to reply to this than your other mail, so...
I think the reason people dont want to enable the hard-fail at this point is
that its been almost 4 years since the Cmake build was added and while we said
at the time we would deprecate Automake builds, we never have...people will not
expect it to fail as we gave no recent warning it would.
If we at least make an attempt to tell them now [4 months, 1 release] in advance
that we are going to do that, its much harder to complain about the abrupt
failure of automated builds etc etc.
So basically, being friendly is the main reason not to break builds immediately.
I've been swayed. I will not deploy the fiendish plan. Will commit updated docs
and a passive message from configure shortly.
On 15 March 2013 14:29, Alan Conway <[email protected]
<mailto:[email protected]>> wrote:
On 03/15/2013 10:24 AM, Robbie Gemmell wrote:
Would it also be an idea to have the 0.22 Automake build echo a message
indicating that it will become deprecated in the next release and
removed
in the release after that?
Lots of people dont read readme files and thus wont actually find out
until
they try 0.24 and discover it wont work until they add the option to
enable
it, and it might be helpful to try and inform them now.
+1. I propose a slightly stronger version: configure will _fail_ by default
and print the message. Users can continue to use automake by adding
--enable-deprecated=yes to configure.
Robbie
On 11 March 2013 18:59, Andrew Stitcher <[email protected]
<mailto:[email protected]>> wrote:
On Mon, 2013-03-11 at 14:24 -0400, Alan Conway wrote:
On 03/11/2013 01:24 PM, Andrew Stitcher wrote:
...
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.
Sorry not to be clear enough.
Before and for the 0.22 release (the one that just went into alpha)
We
should make sure we get the README and unix build instructions up to
date and telling people how to use cmake and elevating it to the
preferred method in the README (leave the autotools instructions in
at
the bottom and note them as deprecated - but for 0.22 only in these
docs)
Then for 0.24, (ie on trunk as soon as we release 0.22) we carry out
your fiendish scheme of making the autotools configure fail with a
warning etc.
Then for 0.26 We actually remove autotools completely.
The idea here is to get people building 0.22 with cmake by making
it the
preferred instruction in the README/INSTALL doc and reporting bugs
to
us, but to still "allow" them and support them building with
autotools
if it fails badly for them for some reason.
The corollary is that failing to build with cmake won't be a
blocker for
0.22, but it will start to be a blocker from 0.24 onwards.
Andrew
------------------------------__------------------------------__---------
To unsubscribe, e-mail: [email protected].__org
<mailto:[email protected]>
For additional commands, e-mail: [email protected]
<mailto:[email protected]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
