I just added a little more detail to hopefully reduce the number of questions that need to get asked repeatedly :)
Robbie On 15 March 2013 20:42, Alan Conway <[email protected]> wrote: > I have been dissuaded from my fiendish scheme, and I have implemented the > non-controversial parts of the proposal to deprecate autotools: > > - mailed user@qpid warning that autotools will be deprecated (but > supported) for 0..22 > - updated INSTALL docs and added a deprecation message to configure in > r1457098. > > I'm keeping > https://issues.apache.org/**jira/browse/QPID-4640<https://issues.apache.org/jira/browse/QPID-4640>open > to track any cmake issues blocking folks from migrating from > autotools. There are already a couple of known (minor) issues noted there. > > I'm going on vacation next week so I look forward to an overflowing inbox > on my return :) > > Cheers, > Alan. > > > On 03/15/2013 11:30 AM, Alan Conway wrote: > >> On 03/15/2013 10:59 AM, Steve Huston wrote: >> >>> Just a small nit... "clearmake" is mentioned a few times below where >>> "cmake" >>> is intended. "clearmake" is another beast all together. >>> >>> >> Yes, sorry. Was having flashbacks. >> >> -----Original Message----- >>>> From: Alan Conway [mailto:[email protected]] >>>> Sent: Friday, March 15, 2013 10:26 AM >>>> To: [email protected] >>>> Cc: Andrew Stitcher; Cliff Jansen >>>> Subject: Re: Proposal: get rid of automake build system. >>>> >>>> On 03/11/2013 02:59 PM, Andrew Stitcher 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) >>>>> >>>> >>>> Agreed. >>>> >>>>> 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. >>>>> >>>> >>>> I think for 0.22 though we need more than just updated docs to get >>>> peoples >>>> attention. People who are used to building qpid probably won't read the >>>> INSTALL instructions again and so won't realize they need to start >>>> converting >>>> until 0.24 is released. Why not put the fiendish scheme in motion in >>>> 0.22? It >>>> doesn't prevent anyone from using autotools, it just ensures that if >>>> they do, >>>> they will be made aware of the need to move to clearmake. Enabling >>>> autotools after reading the warning is trivial: >>>> --enable-deprecated=yes. That >>>> doesn't put an unreasonable strain on people who still want to use >>>> automake, but it guarantees a wider awarenses of the deprecation. >>>> >>>> Then for 0.26 We actually remove autotools completely. >>>>> >>>> >>>> >>>> If we put the fiendish scheme in motion for 0.22 then we could drop >>>> autotools in >>>> 0.24 if things are going smoothly with clearmake. We could also delay >>>> removal till 0.26 if there are still significant problems. Since >>>> everyone >>>> will be >>>> aware of the transition because of the fiendish scheme, the odds are >>>> we'll >>>> flush any bugs out pretty quickly and everything will be smooth by 0.24 >>>> >>>> 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. >>>>> >>>> >>>> That's exactly what the fiendish scheme does!! The only difference is >>>> that >>>> people using autotools are guaranteed to be made aware that there are >>>> important changes in new INSTALL etc. to read. It still allows them to >>>> use >>>> autotools if they don't want to convert immediately. >>>> >>>> >>>> ------------------------------**------------------------------** >>>> --------- >>>> To unsubscribe, e-mail: >>>> [email protected].**org<[email protected]>For >>>> additional >>>> commands, e-mail: [email protected] >>>> >>> >>> >>> ------------------------------**------------------------------** >>> --------- >>> To unsubscribe, e-mail: >>> [email protected].**org<[email protected]> >>> For additional commands, e-mail: [email protected] >>> >>> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> [email protected].**org<[email protected]> >> For additional commands, e-mail: [email protected] >> >> > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > [email protected].**org<[email protected]> > For additional commands, e-mail: [email protected] > >
