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 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] For additional
commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
