You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Alan Conway <ac...@redhat.com> on 2013/03/08 15:56:43 UTC
Proposal: get rid of automake build system.
Having 2 build systems is a waste of time and a source of confusion. We
introduced the cmake build with the intent that it would replace the automake
system, I think the time has come to say farewell to automake. The cmake system
is ready: it covers the same ground as automake and more (esp. windows), and it
is actively and successfully used by many developers.
I propose that once we have branched for the 0.22 release, we delete the
automake build system. That will give us plenty of time to find and fix any
issues with the cmake system before the next release. I'm not aware of any major
deficiencies in the cmake system, minor discrepancies will be quickly found and
fixed once everyone has switched. I volunteer to help resolve issues that come up.
Are there any strong opinions out there for or against? Anyone know of specific
issues that need to be addressed in cmake?
Cheers,
Alan.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Robbie Gemmell <ro...@gmail.com>.
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 <ac...@redhat.com> 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:aconway@redhat.com]
>>>> Sent: Friday, March 15, 2013 10:26 AM
>>>> To: dev@qpid.apache.org
>>>> 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: dev-unsubscribe@qpid.apache.**org<de...@qpid.apache.org>For additional
>>>> commands, e-mail: dev-help@qpid.apache.org
>>>>
>>>
>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.**org<de...@qpid.apache.org>
>>> For additional commands, e-mail: dev-help@qpid.apache.org
>>>
>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.**org<de...@qpid.apache.org>
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.**org<de...@qpid.apache.org>
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Proposal: get rid of automake build system.
Posted by Alan Conway <ac...@redhat.com>.
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:aconway@redhat.com]
>>> Sent: Friday, March 15, 2013 10:26 AM
>>> To: dev@qpid.apache.org
>>> 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: dev-unsubscribe@qpid.apache.org For additional
>>> commands, e-mail: dev-help@qpid.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Alan Conway <ac...@redhat.com>.
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:aconway@redhat.com]
>> Sent: Friday, March 15, 2013 10:26 AM
>> To: dev@qpid.apache.org
>> 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: dev-unsubscribe@qpid.apache.org For additional
>> commands, e-mail: dev-help@qpid.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
RE: Proposal: get rid of automake build system.
Posted by Steve Huston <sh...@riverace.com>.
Just a small nit... "clearmake" is mentioned a few times below where "cmake" is intended. "clearmake" is another beast all together.
> -----Original Message-----
> From: Alan Conway [mailto:aconway@redhat.com]
> Sent: Friday, March 15, 2013 10:26 AM
> To: dev@qpid.apache.org
> 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: dev-unsubscribe@qpid.apache.org For additional
> commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Alan Conway <ac...@redhat.com>.
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: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
I'd definitely agree with that.
This is the sort of thing that should be shouted from the rooftops to
give everyone fair warning and to minimise the likelihood of "I didn't
notice".
Having a deprecation echo along with echoing "please do try cmake
instead and let us know if it doesn't work" would be good.
Carrot and stick and all that!!!
Frase.
On 15/03/13 14:24, 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.
>
> Robbie
>
>
> On 11 March 2013 18:59, Andrew Stitcher <as...@redhat.com> 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: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Rob Godfrey <ro...@gmail.com>.
On 15 March 2013 16:14, Fraser Adams <fr...@blueyonder.co.uk> wrote:
> It would by me :-) and I guess by you given a previous post you made about
> automake finally working for you too.
>
> I rather suspect we might be the guinea pigs :-D
Indeed - though I would also note that the Jenkins CI tests run on
Ubuntu too and we have those building and testing the C++ Broker
(using automake right now)... would be a shame to break the CI builds
too.
What I think the project needs is a clear statement on the platforms
the build is expected to work on... so that if it doesn't we as the
Qpid project are committed to fixing it.
>
> I did hear from a colleague of mine that cmake didn't work on a fairly old
> RH version he had to use, I suggested that he post exactly what he's been
> seeing.
>
> My guess is that the "user" community might be wider and more disparate than
> the "dev" community whom I guess have a lot of RedHat blood, so hopefully
> it'll either "just work" or there'll be an avalanche of bug reports PDQ.
>
> Frase
>
>
-- Rob
>
> On 15/03/13 15:04, Rob Godfrey wrote:
>>
>> Can I ask which platforms/OSs are are going to be "supported" by this
>> build.
>>
>> Obviously you guys care about Fedora/RedHat based systems, and
>> Windows... But would not building on Ubuntu (for instance) be
>> considered a blocker?
>>
>> -- Rob
>>
>>
>> On 15 March 2013 15:29, Alan Conway <ac...@redhat.com> 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 <as...@redhat.com> 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: dev-unsubscribe@qpid.apache.org
>>>>> For additional commands, e-mail: dev-help@qpid.apache.org
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: dev-help@qpid.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
It would by me :-) and I guess by you given a previous post you made
about automake finally working for you too.
I rather suspect we might be the guinea pigs :-D
I did hear from a colleague of mine that cmake didn't work on a fairly
old RH version he had to use, I suggested that he post exactly what he's
been seeing.
My guess is that the "user" community might be wider and more disparate
than the "dev" community whom I guess have a lot of RedHat blood, so
hopefully it'll either "just work" or there'll be an avalanche of bug
reports PDQ.
Frase
On 15/03/13 15:04, Rob Godfrey wrote:
> Can I ask which platforms/OSs are are going to be "supported" by this build.
>
> Obviously you guys care about Fedora/RedHat based systems, and
> Windows... But would not building on Ubuntu (for instance) be
> considered a blocker?
>
> -- Rob
>
>
> On 15 March 2013 15:29, Alan Conway <ac...@redhat.com> 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 <as...@redhat.com> 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: dev-unsubscribe@qpid.apache.org
>>>> For additional commands, e-mail: dev-help@qpid.apache.org
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Rob Godfrey <ro...@gmail.com>.
Can I ask which platforms/OSs are are going to be "supported" by this build.
Obviously you guys care about Fedora/RedHat based systems, and
Windows... But would not building on Ubuntu (for instance) be
considered a blocker?
-- Rob
On 15 March 2013 15:29, Alan Conway <ac...@redhat.com> 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 <as...@redhat.com> 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: dev-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: dev-help@qpid.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Alan Conway <ac...@redhat.com>.
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 <aconway@redhat.com
> <ma...@redhat.com>> 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 <astitcher@redhat.com
> <ma...@redhat.com>> 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: dev-unsubscribe@qpid.apache.__org
> <ma...@qpid.apache.org>
> For additional commands, e-mail: dev-help@qpid.apache.org
> <ma...@qpid.apache.org>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Alan Conway <ac...@redhat.com>.
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 <as...@redhat.com> 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: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Robbie Gemmell <ro...@gmail.com>.
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.
Robbie
On 11 March 2013 18:59, Andrew Stitcher <as...@redhat.com> 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: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Proposal: get rid of automake build system.
Posted by Ken Giusti <kg...@redhat.com>.
+1 Andrew's proposed schedule and Alan's fiendish scheme.
----- Original Message -----
> From: "Andrew Stitcher" <as...@redhat.com>
> To: dev@qpid.apache.org
> Cc: "Cliff Jansen" <cl...@gmail.com>
> Sent: Monday, March 11, 2013 2:59:52 PM
> Subject: Re: Proposal: get rid of automake build system.
>
> 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: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
--
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Andrew Stitcher <as...@redhat.com>.
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: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Alan Conway <ac...@redhat.com>.
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: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Andrew Stitcher <as...@redhat.com>.
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!
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Alan Conway <ac...@redhat.com>.
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.
Does that seem reasonable?
Cheers,
Alan.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Cliff Jansen <cl...@gmail.com>.
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?).
On Fri, Mar 8, 2013 at 10:36 AM, Fraser Adams
<fr...@blueyonder.co.uk> wrote:
> Hi Alan,
> Personally I'd rather cmake was given the heave ho ;->
>
> for all of it's pain automake is something of a defacto standard for a ton
> of projects.
>
> Re "Anyone know of specific issues that need to be addressed in cmake?"
> yeah, I don't have cmake installed :-D sorry. I'm just messing.
>
> Seriously though I've just reached a point with 0.20 where I didn't have to
> hack around with things to get Qpid to compile on my Ubuntu box, so if I'm
> honest I'm a little disinclined to change something that finally works to
> have things potentially break more again.
>
> If there are strong feelings that agree with your view to move to cmake can
> I suggest that deprecation rather than removal of automake is announced. I
> think just deleting it from 0.22 is a bit draconian and I think we should
> have a couple of releases at least where both exist but one is marked
> deprecated so that users get a chance to flag up where things break (plenty
> of users only work off official releases - imagine their surprise if they
> are forced to use cmake and either they don't have cmake installed or the
> cmake breaks for them).
>
> I'm clearly biased 'cause I haven't used cmake, but I'm very anti just
> deleting the automake build without a period of it being properly
> deprecated.
>
> All that said I do have sympathy with the view that having two build systems
> is probably not ideal.
>
> Oh and to follow on a thread that was started a little while back by Gordon
> I *really* think that this proposal should be flagged up on the qpid users
> mailing list too!!
>
> Frase
>
>
>
> On 08/03/13 14:56, Alan Conway wrote:
>>
>> Having 2 build systems is a waste of time and a source of confusion. We
>> introduced the cmake build with the intent that it would replace the
>> automake system, I think the time has come to say farewell to automake. The
>> cmake system is ready: it covers the same ground as automake and more (esp.
>> windows), and it is actively and successfully used by many developers.
>>
>> I propose that once we have branched for the 0.22 release, we delete the
>> automake build system. That will give us plenty of time to find and fix any
>> issues with the cmake system before the next release. I'm not aware of any
>> major deficiencies in the cmake system, minor discrepancies will be quickly
>> found and fixed once everyone has switched. I volunteer to help resolve
>> issues that come up.
>>
>> Are there any strong opinions out there for or against? Anyone know of
>> specific issues that need to be addressed in cmake?
>>
>> Cheers,
>> Alan.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
RE: Proposal: get rid of automake build system.
Posted by Steve Huston <sh...@riverace.com>.
Hi Fraser,
> -----Original Message-----
> From: Fraser Adams [mailto:fraser.adams@blueyonder.co.uk]
> Sent: Friday, March 08, 2013 10:36 AM
> To: dev@qpid.apache.org
> Subject: Re: Proposal: get rid of automake build system.
>
> Hi Alan,
> Personally I'd rather cmake was given the heave ho ;->
Do you have an alternative that works on Windows?
> for all of it's pain automake is something of a defacto standard for a ton of
> projects.
>
> Re "Anyone know of specific issues that need to be addressed in cmake?"
> yeah, I don't have cmake installed :-D sorry. I'm just messing.
>
> Seriously though I've just reached a point with 0.20 where I didn't have to
> hack around with things to get Qpid to compile on my Ubuntu box, so if I'm
> honest I'm a little disinclined to change something that finally works to have
> things potentially break more again.
>
> If there are strong feelings that agree with your view to move to cmake can I
> suggest that deprecation rather than removal of automake is announced. I
> think just deleting it from 0.22 is a bit draconian and I think we should have a
> couple of releases at least where both exist but one is marked deprecated so
> that users get a chance to flag up where things break (plenty of users only
> work off official releases - imagine their surprise if they are forced to use
> cmake and either they don't have cmake installed or the cmake breaks for
> them).
The automake build has been deprecated for a number of years now, IIRC.
> I'm clearly biased 'cause I haven't used cmake, but I'm very anti just deleting
> the automake build without a period of it being properly deprecated.
>
> All that said I do have sympathy with the view that having two build systems
> is probably not ideal.
>
> Oh and to follow on a thread that was started a little while back by Gordon I
> *really* think that this proposal should be flagged up on the qpid users
> mailing list too!!
Decent point, yes. But let's clear the devs first since they will be the main bearers of any burden.
> Frase
>
>
> On 08/03/13 14:56, Alan Conway wrote:
> > Having 2 build systems is a waste of time and a source of confusion.
> > We introduced the cmake build with the intent that it would replace
> > the automake system, I think the time has come to say farewell to
> > automake. The cmake system is ready: it covers the same ground as
> > automake and more (esp. windows), and it is actively and successfully
> > used by many developers.
> >
> > I propose that once we have branched for the 0.22 release, we delete
> > the automake build system. That will give us plenty of time to find
> > and fix any issues with the cmake system before the next release. I'm
> > not aware of any major deficiencies in the cmake system, minor
> > discrepancies will be quickly found and fixed once everyone has
> > switched. I volunteer to help resolve issues that come up.
> >
> > Are there any strong opinions out there for or against? Anyone know of
> > specific issues that need to be addressed in cmake?
> >
> > Cheers,
> > Alan.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org For additional
> > commands, e-mail: dev-help@qpid.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org For additional
> commands, e-mail: dev-help@qpid.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Andrew Stitcher <as...@redhat.com>.
On Sat, 2013-03-09 at 09:24 +0000, Fraser Adams wrote:
> ...
> I'm surprised that you are surprised. I'd have thought that the place
> most people first look for Qpid downloads is:
>
> http://qpid.apache.org/download.html
>
> and that only actually mentions Fedora packages
Hmm, interesting, when I want to install something (on either fedora or
ubuntu/debian) the first thing I'd do would be apt-get/yum. So obviously
I assume that everyone else is the same. I thought there were official
qpid packages now for ubuntu/debian if not then obviously you will end
up compiling from source and also it may not be as up to date as you;d
like too.
> ...
> Then there's the endless fun relating to boost dependencies - plenty of
> systems that use Qpid also have boost deployed for other reasons and
> it's not notorious for having great interoperability between different
> versions. I definitely know of people having to juggle things due to boost.
Yes, boost dependencies are a real pain and if our users actually
pointed out how much of a pain we could probably prioritise mitigating
this completely now.
For the Unix port of qpid we only need one boost library
(program_options) linked in and this is what forces the dependency
problems. Most of our us of boost is header file code only, and even a
large part of that is now in the standard library. This means that there
would be no installed dependency on boost, but further it would be
possible (although it's not clear how desirable) to fix a version of
boost and copy the needed header files into our tree and avoid any
external dependency. boost even has a utility to do this - bcp.
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Alan Conway <ac...@redhat.com>.
On 03/11/2013 02:55 PM, Fraser Adams wrote:
>
>> So I've opened https://issues.apache.org/jira/browse/QPID-4640, which makes
>> deprecation clear and gives us at least 1 more release cycle to fix any issues
>> that crop up. Does that seem reasonable?
>>
>>
> That seems fair, but I'll reiterate my broken record and suggest that now seems
> like a real good time to break the news to the user mailing list.
>
> Frase
>
Will do.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
> So I've opened https://issues.apache.org/jira/browse/QPID-4640, which
> makes deprecation clear and gives us at least 1 more release cycle to
> fix any issues that crop up. Does that seem reasonable?
>
>
That seems fair, but I'll reiterate my broken record and suggest that
now seems like a real good time to break the news to the user mailing list.
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Alan Conway <ac...@redhat.com>.
On 03/11/2013 02:35 PM, Fraser Adams wrote:
>
>> So... the automake build works fine (which is a new experience on
>> Ubuntu :-) )....
>>
>> So I'd personally not be keen to remove the automake build until the
>> cmake build works on my platform :-)
>>
>> -- Rob
>>
> Ha ha, yeah that was the original source of my amusement/bemusement. I'd noticed
> with 0.20 that Gordon and co had applied a patch that I'd raised back in 0.12 to
> get it working on Ubuntu. There was a bit of irony around the proposal to move
> to cmake when we'd just got the automake build "just working" :-) though I can
> see why it might be a good move.
>
> I think some of the recent proposals around pushing the "automake *really* is
> deprecated please use cmake and report any issues" agenda seem to be a good
> middle ground. I think a couple of releases to give users a chance to shout
> seems fair warning.
>
So I've opened https://issues.apache.org/jira/browse/QPID-4640, which makes
deprecation clear and gives us at least 1 more release cycle to fix any issues
that crop up. Does that seem reasonable?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
> So... the automake build works fine (which is a new experience on
> Ubuntu :-) )....
>
> So I'd personally not be keen to remove the automake build until the
> cmake build works on my platform :-)
>
> -- Rob
>
Ha ha, yeah that was the original source of my amusement/bemusement. I'd
noticed with 0.20 that Gordon and co had applied a patch that I'd raised
back in 0.12 to get it working on Ubuntu. There was a bit of irony
around the proposal to move to cmake when we'd just got the automake
build "just working" :-) though I can see why it might be a good move.
I think some of the recent proposals around pushing the "automake
*really* is deprecated please use cmake and report any issues" agenda
seem to be a good middle ground. I think a couple of releases to give
users a chance to shout seems fair warning.
I'm kind of glad I wasn't the only one seeing Ubuntu weirdness.
I'll have a play with cmake myself when I get a moment.
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
RE: Proposal: get rid of automake build system.
Posted by Steve Huston <sh...@riverace.com>.
> -----Original Message-----
> From: Rob Godfrey [mailto:rob.j.godfrey@gmail.com]
> Sent: Monday, March 11, 2013 1:32 PM
> To: dev@qpid.apache.org
> Subject: Re: Proposal: get rid of automake build system.
>
> On 11 March 2013 18:21, Andrew Stitcher <as...@redhat.com> wrote:
> > On Mon, 2013-03-11 at 18:09 +0100, Rob Godfrey wrote:
> >> OK... So on a completely fresh checkout (it seems like it doesn't
> >> deal very well with having some remenants of an old build on automake
> >> somewhere - even though I blew away everything I could see)...
> >>
> >> it gets a lot further, but then dies with the following:
> >>
> >> inking CXX shared library libsslcommon.so
> >> CMakeFiles/sslcommon.dir/qpid/sys/ssl/check.o: In function
> >> `qpid::sys::ssl::ErrorString::ErrorString()':
> >> check.cpp:(.text+0xd): undefined reference to `PR_GetError'
> >> check.cpp:(.text+0x1a): undefined reference to `PR_GetErrorTextLength'
> >> check.cpp:(.text+0x3f): undefined reference to `PR_GetErrorText'
> >> CMakeFiles/sslcommon.dir/qpid/sys/ssl/util.o: In function
> >> `qpid::sys::ssl::promptForPassword(PK11SlotInfoStr*, int, void*)':
> >> util.cpp:(.text+0x3b8): undefined reference to `PL_strdup'
> >> CMakeFiles/sslcommon.dir/qpid/sys/ssl/util.o: In function
> >> `qpid::sys::ssl::readPasswordFromFile(PK11SlotInfoStr*, int, void*)':
> >> util.cpp:(.text+0x4b9): undefined reference to `PL_strdup'
> >> CMakeFiles/sslcommon.dir/qpid/sys/ssl/util.o: In function
> >> `qpid::sys::ssl::initNSS(qpid::sys::ssl::SslOptions const&, bool)':
> >> util.cpp:(.text+0x58a): undefined reference to `PK11_SetPasswordFunc'
> >> util.cpp:(.text+0x59b): undefined reference to `PK11_SetPasswordFunc'
> >> util.cpp:(.text+0x5b6): undefined reference to `NSS_Init'
> >> util.cpp:(.text+0x6a7): undefined reference to `NSS_SetExportPolicy'
> >> util.cpp:(.text+0x779): undefined reference to `NSS_SetDomesticPolicy'
> >> util.cpp:(.text+0x86c): undefined reference to
> `SSL_ConfigServerSessionIDCache'
> >> CMakeFiles/sslcommon.dir/qpid/sys/ssl/util.o: In function
> >> `qpid::sys::ssl::shutdownNSS()':
> >> util.cpp:(.text+0x93b): undefined reference to `NSS_Shutdown'
> >> CMakeFiles/sslcommon.dir/qpid/sys/ssl/SslSocket.o: In function
> >> `qpid::sys::ssl::SslSocket::SslSocket(std::basic_string<char,
> >> std::char_traits<char>, std::allocator<char> > const&, bool)':
> >>
> >> ... and so on
> >>
> >> Presumably this is some SSL library incompatibility?
> >
> > Doesn't look like an incompatibility per se, rather a failure of the
> > cmake script to correctly find the library link directory for nss3.
> > Curious - I thought the NSS3 detection was a module supplied with
> > cmake, and so should "just work".
> >
> > Andrew
> >
>
> So... the automake build works fine (which is a new experience on Ubuntu :-)
> )....
>
> So I'd personally not be keen to remove the automake build until the cmake
> build works on my platform :-)
Looks like you just volunteered to fix the cmake build on Ubuntu ;-)
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Rob Godfrey <ro...@gmail.com>.
On 11 March 2013 18:21, Andrew Stitcher <as...@redhat.com> wrote:
> On Mon, 2013-03-11 at 18:09 +0100, Rob Godfrey wrote:
>> OK... So on a completely fresh checkout (it seems like it doesn't deal
>> very well with having some remenants of an old build on automake
>> somewhere - even though I blew away everything I could see)...
>>
>> it gets a lot further, but then dies with the following:
>>
>> inking CXX shared library libsslcommon.so
>> CMakeFiles/sslcommon.dir/qpid/sys/ssl/check.o: In function
>> `qpid::sys::ssl::ErrorString::ErrorString()':
>> check.cpp:(.text+0xd): undefined reference to `PR_GetError'
>> check.cpp:(.text+0x1a): undefined reference to `PR_GetErrorTextLength'
>> check.cpp:(.text+0x3f): undefined reference to `PR_GetErrorText'
>> CMakeFiles/sslcommon.dir/qpid/sys/ssl/util.o: In function
>> `qpid::sys::ssl::promptForPassword(PK11SlotInfoStr*, int, void*)':
>> util.cpp:(.text+0x3b8): undefined reference to `PL_strdup'
>> CMakeFiles/sslcommon.dir/qpid/sys/ssl/util.o: In function
>> `qpid::sys::ssl::readPasswordFromFile(PK11SlotInfoStr*, int, void*)':
>> util.cpp:(.text+0x4b9): undefined reference to `PL_strdup'
>> CMakeFiles/sslcommon.dir/qpid/sys/ssl/util.o: In function
>> `qpid::sys::ssl::initNSS(qpid::sys::ssl::SslOptions const&, bool)':
>> util.cpp:(.text+0x58a): undefined reference to `PK11_SetPasswordFunc'
>> util.cpp:(.text+0x59b): undefined reference to `PK11_SetPasswordFunc'
>> util.cpp:(.text+0x5b6): undefined reference to `NSS_Init'
>> util.cpp:(.text+0x6a7): undefined reference to `NSS_SetExportPolicy'
>> util.cpp:(.text+0x779): undefined reference to `NSS_SetDomesticPolicy'
>> util.cpp:(.text+0x86c): undefined reference to `SSL_ConfigServerSessionIDCache'
>> CMakeFiles/sslcommon.dir/qpid/sys/ssl/util.o: In function
>> `qpid::sys::ssl::shutdownNSS()':
>> util.cpp:(.text+0x93b): undefined reference to `NSS_Shutdown'
>> CMakeFiles/sslcommon.dir/qpid/sys/ssl/SslSocket.o: In function
>> `qpid::sys::ssl::SslSocket::SslSocket(std::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const&, bool)':
>>
>> ... and so on
>>
>> Presumably this is some SSL library incompatibility?
>
> Doesn't look like an incompatibility per se, rather a failure of the
> cmake script to correctly find the library link directory for nss3.
> Curious - I thought the NSS3 detection was a module supplied with cmake,
> and so should "just work".
>
> Andrew
>
So... the automake build works fine (which is a new experience on
Ubuntu :-) )....
So I'd personally not be keen to remove the automake build until the
cmake build works on my platform :-)
-- Rob
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Andrew Stitcher <as...@redhat.com>.
On Mon, 2013-03-11 at 18:09 +0100, Rob Godfrey wrote:
> OK... So on a completely fresh checkout (it seems like it doesn't deal
> very well with having some remenants of an old build on automake
> somewhere - even though I blew away everything I could see)...
>
> it gets a lot further, but then dies with the following:
>
> inking CXX shared library libsslcommon.so
> CMakeFiles/sslcommon.dir/qpid/sys/ssl/check.o: In function
> `qpid::sys::ssl::ErrorString::ErrorString()':
> check.cpp:(.text+0xd): undefined reference to `PR_GetError'
> check.cpp:(.text+0x1a): undefined reference to `PR_GetErrorTextLength'
> check.cpp:(.text+0x3f): undefined reference to `PR_GetErrorText'
> CMakeFiles/sslcommon.dir/qpid/sys/ssl/util.o: In function
> `qpid::sys::ssl::promptForPassword(PK11SlotInfoStr*, int, void*)':
> util.cpp:(.text+0x3b8): undefined reference to `PL_strdup'
> CMakeFiles/sslcommon.dir/qpid/sys/ssl/util.o: In function
> `qpid::sys::ssl::readPasswordFromFile(PK11SlotInfoStr*, int, void*)':
> util.cpp:(.text+0x4b9): undefined reference to `PL_strdup'
> CMakeFiles/sslcommon.dir/qpid/sys/ssl/util.o: In function
> `qpid::sys::ssl::initNSS(qpid::sys::ssl::SslOptions const&, bool)':
> util.cpp:(.text+0x58a): undefined reference to `PK11_SetPasswordFunc'
> util.cpp:(.text+0x59b): undefined reference to `PK11_SetPasswordFunc'
> util.cpp:(.text+0x5b6): undefined reference to `NSS_Init'
> util.cpp:(.text+0x6a7): undefined reference to `NSS_SetExportPolicy'
> util.cpp:(.text+0x779): undefined reference to `NSS_SetDomesticPolicy'
> util.cpp:(.text+0x86c): undefined reference to `SSL_ConfigServerSessionIDCache'
> CMakeFiles/sslcommon.dir/qpid/sys/ssl/util.o: In function
> `qpid::sys::ssl::shutdownNSS()':
> util.cpp:(.text+0x93b): undefined reference to `NSS_Shutdown'
> CMakeFiles/sslcommon.dir/qpid/sys/ssl/SslSocket.o: In function
> `qpid::sys::ssl::SslSocket::SslSocket(std::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&, bool)':
>
> ... and so on
>
> Presumably this is some SSL library incompatibility?
Doesn't look like an incompatibility per se, rather a failure of the
cmake script to correctly find the library link directory for nss3.
Curious - I thought the NSS3 detection was a module supplied with cmake,
and so should "just work".
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Rob Godfrey <ro...@gmail.com>.
OK... So on a completely fresh checkout (it seems like it doesn't deal
very well with having some remenants of an old build on automake
somewhere - even though I blew away everything I could see)...
it gets a lot further, but then dies with the following:
inking CXX shared library libsslcommon.so
CMakeFiles/sslcommon.dir/qpid/sys/ssl/check.o: In function
`qpid::sys::ssl::ErrorString::ErrorString()':
check.cpp:(.text+0xd): undefined reference to `PR_GetError'
check.cpp:(.text+0x1a): undefined reference to `PR_GetErrorTextLength'
check.cpp:(.text+0x3f): undefined reference to `PR_GetErrorText'
CMakeFiles/sslcommon.dir/qpid/sys/ssl/util.o: In function
`qpid::sys::ssl::promptForPassword(PK11SlotInfoStr*, int, void*)':
util.cpp:(.text+0x3b8): undefined reference to `PL_strdup'
CMakeFiles/sslcommon.dir/qpid/sys/ssl/util.o: In function
`qpid::sys::ssl::readPasswordFromFile(PK11SlotInfoStr*, int, void*)':
util.cpp:(.text+0x4b9): undefined reference to `PL_strdup'
CMakeFiles/sslcommon.dir/qpid/sys/ssl/util.o: In function
`qpid::sys::ssl::initNSS(qpid::sys::ssl::SslOptions const&, bool)':
util.cpp:(.text+0x58a): undefined reference to `PK11_SetPasswordFunc'
util.cpp:(.text+0x59b): undefined reference to `PK11_SetPasswordFunc'
util.cpp:(.text+0x5b6): undefined reference to `NSS_Init'
util.cpp:(.text+0x6a7): undefined reference to `NSS_SetExportPolicy'
util.cpp:(.text+0x779): undefined reference to `NSS_SetDomesticPolicy'
util.cpp:(.text+0x86c): undefined reference to `SSL_ConfigServerSessionIDCache'
CMakeFiles/sslcommon.dir/qpid/sys/ssl/util.o: In function
`qpid::sys::ssl::shutdownNSS()':
util.cpp:(.text+0x93b): undefined reference to `NSS_Shutdown'
CMakeFiles/sslcommon.dir/qpid/sys/ssl/SslSocket.o: In function
`qpid::sys::ssl::SslSocket::SslSocket(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&, bool)':
... and so on
Presumably this is some SSL library incompatibility?
-- Rob
On 11 March 2013 17:02, Rob Godfrey <ro...@gmail.com> wrote:
> Hmmm...
>
> it never gets far enough for the install prefix to make a difference
> :-( (incidentally where is cmake mentioned in the docs - I can see it
> in the windows README-winsdk.txt but not in README.txt which talks
> exclusively about linux AFAICT)
>
> rob@humpy:~/qpid-trunk/qpid/cpp/build$ make clean
> rob@humpy:~/qpid-trunk/qpid/cpp/build$ make
> [ 1%] Building CXX object src/CMakeFiles/qpidtypes.dir/qpid/types/Exception.o
> [ 1%] Building CXX object src/CMakeFiles/qpidtypes.dir/qpid/types/Uuid.o
> [ 1%] Building CXX object src/CMakeFiles/qpidtypes.dir/qpid/types/Variant.o
> Linking CXX shared library libqpidtypes.so
> [ 1%] Built target qpidtypes
> [ 1%] Building CXX object
> src/CMakeFiles/qpidcommon.dir/qpid/framing/ExchangeBoundResult.o
> /home/rob/qpid-trunk/qpid/cpp/build/src/qpid/framing/ExchangeBoundResult.cpp:
> In member function ‘void
> qpid::framing::ExchangeBoundResult::decode(qpid::framing::Buffer&,
> uint32_t)’:
> /home/rob/qpid-trunk/qpid/cpp/build/src/qpid/framing/ExchangeBoundResult.cpp:83:90:
> error: ‘FramingErrorException’ was not declared in this scope
> make[2]: *** [src/CMakeFiles/qpidcommon.dir/qpid/framing/ExchangeBoundResult.o]
> Error 1
> make[1]: *** [src/CMakeFiles/qpidcommon.dir/all] Error 2
> make: *** [all] Error 2
>
> This is on an Ubuntu 12.04 64 bit system
>
> -- Rob
>
> On 11 March 2013 16:53, Michael Goulish <mg...@redhat.com> wrote:
>> There are build instructions for linux and windows in the top-level
>> README, but the cmake line only differs from what you are doing in
>> its install prefix:
>>
>> cmake -DCMAKE_INSTALL_PREFIX=/usr ..
>>
>>
>>
>>
>>
>> ----- Original Message -----
>> So... apologies if I am missing them, but are there instructions as to
>> how to build the C++ codebase using cmake?
>>
>> My experience with proton was that
>>
>> mkdir build ; cd build ; cmake .. ; make
>>
>> Would work... But that fails to compile with the C++ broker on my system.
>>
>> -- Rob
>>
>> On 11 March 2013 15:45, Gordon Sim <gs...@redhat.com> wrote:
>>> On 03/09/2013 09:24 AM, Fraser Adams wrote:
>>>>
>>>> On 08/03/13 21:41, Andrew Stitcher wrote:
>>>>>
>>>>> . Anyway if it is anything the dev list is for discussion amongst the
>>>>> qpid developers themselves (rather than developers who use qpid) and
>>>>> surely they are the ons who "get to vote" about the build system.
>>>>
>>>> That's a fair point, but all I'm arguing for is good communication. So
>>>> users don't get a vote - that's fine, but at least if they are able to
>>>> register any worries about the potential impact then the scale of the
>>>> short term support problem that might occur moving users who need to
>>>> build qpid themselves will be better known. If we break something that
>>>> users depend upon without communicating that fact then we risk pushing
>>>> them away.
>>>
>>>
>>> I agree completely. Issues that affect 'users' should be discussed on the
>>> user list. The build system is absolutely one of those things (since the
>>> Apache Qpid community only publishes source builds for c++).
>>>
>>> The lack of awareness of the reasons for moving to cmake and the eventual
>>> removal of autotools is probably itself a result of a failure to adequately
>>> inform users of plans.
>>>
>>> I am in support of Alan's proposal and agree with Fraser that we need to
>>> communicate with users. As far as I understood it, the proposal was to
>>> remove autotools *after* 0.22, not for it.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: dev-help@qpid.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Rob Godfrey <ro...@gmail.com>.
Hmmm...
it never gets far enough for the install prefix to make a difference
:-( (incidentally where is cmake mentioned in the docs - I can see it
in the windows README-winsdk.txt but not in README.txt which talks
exclusively about linux AFAICT)
rob@humpy:~/qpid-trunk/qpid/cpp/build$ make clean
rob@humpy:~/qpid-trunk/qpid/cpp/build$ make
[ 1%] Building CXX object src/CMakeFiles/qpidtypes.dir/qpid/types/Exception.o
[ 1%] Building CXX object src/CMakeFiles/qpidtypes.dir/qpid/types/Uuid.o
[ 1%] Building CXX object src/CMakeFiles/qpidtypes.dir/qpid/types/Variant.o
Linking CXX shared library libqpidtypes.so
[ 1%] Built target qpidtypes
[ 1%] Building CXX object
src/CMakeFiles/qpidcommon.dir/qpid/framing/ExchangeBoundResult.o
/home/rob/qpid-trunk/qpid/cpp/build/src/qpid/framing/ExchangeBoundResult.cpp:
In member function ‘void
qpid::framing::ExchangeBoundResult::decode(qpid::framing::Buffer&,
uint32_t)’:
/home/rob/qpid-trunk/qpid/cpp/build/src/qpid/framing/ExchangeBoundResult.cpp:83:90:
error: ‘FramingErrorException’ was not declared in this scope
make[2]: *** [src/CMakeFiles/qpidcommon.dir/qpid/framing/ExchangeBoundResult.o]
Error 1
make[1]: *** [src/CMakeFiles/qpidcommon.dir/all] Error 2
make: *** [all] Error 2
This is on an Ubuntu 12.04 64 bit system
-- Rob
On 11 March 2013 16:53, Michael Goulish <mg...@redhat.com> wrote:
> There are build instructions for linux and windows in the top-level
> README, but the cmake line only differs from what you are doing in
> its install prefix:
>
> cmake -DCMAKE_INSTALL_PREFIX=/usr ..
>
>
>
>
>
> ----- Original Message -----
> So... apologies if I am missing them, but are there instructions as to
> how to build the C++ codebase using cmake?
>
> My experience with proton was that
>
> mkdir build ; cd build ; cmake .. ; make
>
> Would work... But that fails to compile with the C++ broker on my system.
>
> -- Rob
>
> On 11 March 2013 15:45, Gordon Sim <gs...@redhat.com> wrote:
>> On 03/09/2013 09:24 AM, Fraser Adams wrote:
>>>
>>> On 08/03/13 21:41, Andrew Stitcher wrote:
>>>>
>>>> . Anyway if it is anything the dev list is for discussion amongst the
>>>> qpid developers themselves (rather than developers who use qpid) and
>>>> surely they are the ons who "get to vote" about the build system.
>>>
>>> That's a fair point, but all I'm arguing for is good communication. So
>>> users don't get a vote - that's fine, but at least if they are able to
>>> register any worries about the potential impact then the scale of the
>>> short term support problem that might occur moving users who need to
>>> build qpid themselves will be better known. If we break something that
>>> users depend upon without communicating that fact then we risk pushing
>>> them away.
>>
>>
>> I agree completely. Issues that affect 'users' should be discussed on the
>> user list. The build system is absolutely one of those things (since the
>> Apache Qpid community only publishes source builds for c++).
>>
>> The lack of awareness of the reasons for moving to cmake and the eventual
>> removal of autotools is probably itself a result of a failure to adequately
>> inform users of plans.
>>
>> I am in support of Alan's proposal and agree with Fraser that we need to
>> communicate with users. As far as I understood it, the proposal was to
>> remove autotools *after* 0.22, not for it.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Gordon Sim <gs...@redhat.com>.
On 03/11/2013 03:45 PM, Rob Godfrey wrote:
> So... apologies if I am missing them, but are there instructions as to
> how to build the C++ codebase using cmake?
>
> My experience with proton was that
>
> mkdir build ; cd build ; cmake .. ; make
>
> Would work... But that fails to compile with the C++ broker on my system.
That should work, how is it failing?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Michael Goulish <mg...@redhat.com>.
There are build instructions for linux and windows in the top-level
README, but the cmake line only differs from what you are doing in
its install prefix:
cmake -DCMAKE_INSTALL_PREFIX=/usr ..
----- Original Message -----
So... apologies if I am missing them, but are there instructions as to
how to build the C++ codebase using cmake?
My experience with proton was that
mkdir build ; cd build ; cmake .. ; make
Would work... But that fails to compile with the C++ broker on my system.
-- Rob
On 11 March 2013 15:45, Gordon Sim <gs...@redhat.com> wrote:
> On 03/09/2013 09:24 AM, Fraser Adams wrote:
>>
>> On 08/03/13 21:41, Andrew Stitcher wrote:
>>>
>>> . Anyway if it is anything the dev list is for discussion amongst the
>>> qpid developers themselves (rather than developers who use qpid) and
>>> surely they are the ons who "get to vote" about the build system.
>>
>> That's a fair point, but all I'm arguing for is good communication. So
>> users don't get a vote - that's fine, but at least if they are able to
>> register any worries about the potential impact then the scale of the
>> short term support problem that might occur moving users who need to
>> build qpid themselves will be better known. If we break something that
>> users depend upon without communicating that fact then we risk pushing
>> them away.
>
>
> I agree completely. Issues that affect 'users' should be discussed on the
> user list. The build system is absolutely one of those things (since the
> Apache Qpid community only publishes source builds for c++).
>
> The lack of awareness of the reasons for moving to cmake and the eventual
> removal of autotools is probably itself a result of a failure to adequately
> inform users of plans.
>
> I am in support of Alan's proposal and agree with Fraser that we need to
> communicate with users. As far as I understood it, the proposal was to
> remove autotools *after* 0.22, not for it.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Rob Godfrey <ro...@gmail.com>.
So... apologies if I am missing them, but are there instructions as to
how to build the C++ codebase using cmake?
My experience with proton was that
mkdir build ; cd build ; cmake .. ; make
Would work... But that fails to compile with the C++ broker on my system.
-- Rob
On 11 March 2013 15:45, Gordon Sim <gs...@redhat.com> wrote:
> On 03/09/2013 09:24 AM, Fraser Adams wrote:
>>
>> On 08/03/13 21:41, Andrew Stitcher wrote:
>>>
>>> . Anyway if it is anything the dev list is for discussion amongst the
>>> qpid developers themselves (rather than developers who use qpid) and
>>> surely they are the ons who "get to vote" about the build system.
>>
>> That's a fair point, but all I'm arguing for is good communication. So
>> users don't get a vote - that's fine, but at least if they are able to
>> register any worries about the potential impact then the scale of the
>> short term support problem that might occur moving users who need to
>> build qpid themselves will be better known. If we break something that
>> users depend upon without communicating that fact then we risk pushing
>> them away.
>
>
> I agree completely. Issues that affect 'users' should be discussed on the
> user list. The build system is absolutely one of those things (since the
> Apache Qpid community only publishes source builds for c++).
>
> The lack of awareness of the reasons for moving to cmake and the eventual
> removal of autotools is probably itself a result of a failure to adequately
> inform users of plans.
>
> I am in support of Alan's proposal and agree with Fraser that we need to
> communicate with users. As far as I understood it, the proposal was to
> remove autotools *after* 0.22, not for it.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Gordon Sim <gs...@redhat.com>.
On 03/09/2013 09:24 AM, Fraser Adams wrote:
> On 08/03/13 21:41, Andrew Stitcher wrote:
>> . Anyway if it is anything the dev list is for discussion amongst the
>> qpid developers themselves (rather than developers who use qpid) and
>> surely they are the ons who "get to vote" about the build system.
> That's a fair point, but all I'm arguing for is good communication. So
> users don't get a vote - that's fine, but at least if they are able to
> register any worries about the potential impact then the scale of the
> short term support problem that might occur moving users who need to
> build qpid themselves will be better known. If we break something that
> users depend upon without communicating that fact then we risk pushing
> them away.
I agree completely. Issues that affect 'users' should be discussed on
the user list. The build system is absolutely one of those things (since
the Apache Qpid community only publishes source builds for c++).
The lack of awareness of the reasons for moving to cmake and the
eventual removal of autotools is probably itself a result of a failure
to adequately inform users of plans.
I am in support of Alan's proposal and agree with Fraser that we need to
communicate with users. As far as I understood it, the proposal was to
remove autotools *after* 0.22, not for it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
On 08/03/13 21:41, Andrew Stitcher wrote:
> I'm genuinely surprised that a significant number of people are still
> compiling stuff from source themselves (except what they are actually
> working on themselves of course).
I'm surprised that you are surprised. I'd have thought that the place
most people first look for Qpid downloads is:
http://qpid.apache.org/download.html
and that only actually mentions Fedora packages, unless I've missed
something elsewhere? I'm aware that Cajus Polmeir has been involved in
packaging for Ubuntu, but I've been reluctant to go down that path as
I'm not totally sure where the "official" packaging lives and Googling
"qpid 0.20 ubuntu" or even "qpid 0.18 ubuntu" doesn't yield obvious results.
Then there's the endless fun relating to boost dependencies - plenty of
systems that use Qpid also have boost deployed for other reasons and
it's not notorious for having great interoperability between different
versions. I definitely know of people having to juggle things due to boost.
In an ideal world I'd absolutely agree with the view that people should
be able to just install Qpid and not care about the build stuff, but I
really don't think that we're there.
I may be wrong, but if I am at the very least the documentation needs to
be improved to point people at the packages for the main distros.
> . Anyway if it is anything the dev list is for discussion amongst the
> qpid developers themselves (rather than developers who use qpid) and
> surely they are the ons who "get to vote" about the build system.
That's a fair point, but all I'm arguing for is good communication. So
users don't get a vote - that's fine, but at least if they are able to
register any worries about the potential impact then the scale of the
short term support problem that might occur moving users who need to
build qpid themselves will be better known. If we break something that
users depend upon without communicating that fact then we risk pushing
them away.
>>
>>
>> export LDFLAGS=-L`dirname $(pwd)`/cpp/src/.libs
> But this is due to not installing in the default ubuntu location,
> nothing to do with the qpid build.
I'm not sure that I know what you mean there. I've certainly not changed
the build prefix so it's very much trying to install into *a* default
location. My Qpid build installs into /usr/local/lib, /usr/local/sbin,
/usr/local/bin
I'm certainly not trying to install anywhere unusual.
By "default ubuntu location" are you suggesting that if I put the source
into /usr/local/src I wouldn't have to do the LDFLAGS stuff? I guess
that the problem there is that I then have to sudo everything rather
than just the make install - possibly no big deal though
> If you wanted you could also go
> fiddle with /etc/ld.so.conf.d files
My point was that I didn't actually want to fiddle with anything LDFLAGS
let alone /etc/ld.so.conf.d files in an ideal world it would "just work"
I actually do like the idea of Qpid users being able to just install and
use, so I'm more than happy for that to be an aim, but for that to work
effectively I think that there needs to be engagement with the user
community to get people to try things out in their environments. I guess
that there are a lot more people in the user community than dev
community and as I mentioned previously I expect that there's a more
disparate set of environments.
>
> Actually running your own built executables is something that will just
> work with cmake - the .libs stuff which comes with libtool is much
> harder (BTW you can use libtool itself to get the paths correct somthing
> like libtool --mode=execute ...)
>
> Andrew
>
Thanks, I will have a go with cmake.
I'm not trying to be overly anti this (lack of familiarity and the fact
that I'd finally got a fairly clean build are my main two prejudices :-)
which perhaps isn't the strongest arguing position ;->). The main thrust
of my argument is not so much about whether to move to cmake, rather
it's about making sure that the communication channels are good and to
make sure that we don't inadvertently pull the rug out from under
people, hopefully that doesn't sound too unreasonable?
Best regards,
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Andrew Stitcher <as...@redhat.com>.
On Fri, 2013-03-08 at 18:06 +0000, Fraser Adams wrote:
> > This seems sensible, although it does raise the question of what is
> > 'dev' about this list if the choice of build system is a 'user' issue!
> >
> > Andrew
> >
> >
> That was pretty much the point that Gordon was making :-) There's kind
> of a blurry line between Qpid users and developers - certainly given
> that for many cases users actually have to build Qpid from source in
> order to use it. I guess that the user community is also likely to be
> far more disparate, possibly on a wider set of platforms and very
> possibly blessed :-) AKA restricted by "corporate IT standards". I know
> plenty of cases where people are stuck with ancient OS versions because
> of corporate support policies. So in many ways I'd argue that its the
> user community that this should be flagged up with foremost, because
> clearly you guys have been bubbling around with this thought process for
> a while, but it might come as a surprise to others.
I'm genuinely surprised that a significant number of people are still
compiling stuff from source themselves (except what they are actually
working on themselves of course). Given the decent package repositories
(of all different types) I hardly ever need to compile code dependencies
nowadays. I used to do it a lot in the early 90s, but it seems to be
pretty rare for me now. On Windows it's always been a bit worse though.
Anyway if it is anything the dev list is for discussion amongst the qpid
developers themselves (rather than developers who use qpid) and surely
they are the ons who "get to vote" about the build system.
>
>
> You mentioned "TBH, you shouldn't have to 'hack around' in either case",
> I agree entirely with that statement, but the fact is that I've always
> had to do that because building from source (particularly installing)
> has never "just worked" for me on my Ubuntu system. TBH even with 0.20
> it didn't just work and I had to
>
> export LDFLAGS=-L`dirname $(pwd)`/cpp/src/.libs
But this is due to not installing in the default ubuntu location,
nothing to do with the qpid build. If you wanted you could also go
fiddle with /etc/ld.so.conf.d files
Actually running your own built executables is something that will just
work with cmake - the .libs stuff which comes with libtool is much
harder (BTW you can use libtool itself to get the paths correct somthing
like libtool --mode=execute ...)
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
> This seems sensible, although it does raise the question of what is
> 'dev' about this list if the choice of build system is a 'user' issue!
>
> Andrew
>
>
That was pretty much the point that Gordon was making :-) There's kind
of a blurry line between Qpid users and developers - certainly given
that for many cases users actually have to build Qpid from source in
order to use it. I guess that the user community is also likely to be
far more disparate, possibly on a wider set of platforms and very
possibly blessed :-) AKA restricted by "corporate IT standards". I know
plenty of cases where people are stuck with ancient OS versions because
of corporate support policies. So in many ways I'd argue that its the
user community that this should be flagged up with foremost, because
clearly you guys have been bubbling around with this thought process for
a while, but it might come as a surprise to others.
You mentioned "TBH, you shouldn't have to 'hack around' in either case",
I agree entirely with that statement, but the fact is that I've always
had to do that because building from source (particularly installing)
has never "just worked" for me on my Ubuntu system. TBH even with 0.20
it didn't just work and I had to
export LDFLAGS=-L`dirname $(pwd)`/cpp/src/.libs
before I do ./configure
But 0.12 was a nightmare to make install, which is one of the reasons
that I stayed with that for ages before I plucked up the courage to move
to 0.20
TBH I hadn't realised that the automake stuff was considered deprecated,
I certainly didn't notice anything in README or such like, though
perhaps I just missed it.
I don't want to make a big deal out of it and it sounds like cmake is
the preference, so fair enough and Steve's comment "Do you have an
alternative that works on Windows?" is entirely reasonable - though my
facetious response to that would be delete Windows and install a proper
Operating System :-D (sorry - couldn't help myself, and I'll concede Win
7 is pretty good).
Anyway all the points are fair and I'm not saying don't do it rather
just shout it from the rooftops, say it's deprecated any time a user
asks about make and echo "***** automake is deprecated and will be
deleted in version xyz ***** " in a few places in the build scripts.
Cheers,
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Andrew Stitcher <as...@redhat.com>.
On Fri, 2013-03-08 at 15:36 +0000, Fraser Adams wrote:
> Hi Alan,
> Personally I'd rather cmake was given the heave ho ;->
>
> for all of it's pain automake is something of a defacto standard for a
> ton of projects.
cmake is also a de facto standard (just for a different - albeit smaller
- set of projects)
>
> Re "Anyone know of specific issues that need to be addressed in cmake?"
> yeah, I don't have cmake installed :-D sorry. I'm just messing.
The tests are not at parity, autotools "make check" has quite a lot more
tests wired in than cmake "make test".
>
> Seriously though I've just reached a point with 0.20 where I didn't have
> to hack around with things to get Qpid to compile on my Ubuntu box, so
> if I'm honest I'm a little disinclined to change something that finally
> works to have things potentially break more again.
TBH, you shouldn't have to 'hack around' in either case, you just
install the prerequisites and compile. Substitute cmake for
autoconf/automake/libtool and you are prtty much done.
The actual piece of work here is to rework the README and INSTALL files
to reflect the current build/install process.
>
> If there are strong feelings that agree with your view to move to cmake
> can I suggest that deprecation rather than removal of automake is
> announced. I think just deleting it from 0.22 is a bit draconian and I
> think we should have a couple of releases at least where both exist but
> one is marked deprecated so that users get a chance to flag up where
> things break (plenty of users only work off official releases - imagine
> their surprise if they are forced to use cmake and either they don't
> have cmake installed or the cmake breaks for them).
>
> I'm clearly biased 'cause I haven't used cmake, but I'm very anti just
> deleting the automake build without a period of it being properly
> deprecated.
As Steve said I think the autoconf tool chain has been deprecated so
long that we've forgotten that we did it! My guess is something like 3
years.
We've very clearly demonstrated that without this sort of ultimatum
other things just remain more important.
>
> All that said I do have sympathy with the view that having two build
> systems is probably not ideal.
>
> Oh and to follow on a thread that was started a little while back by
> Gordon I *really* think that this proposal should be flagged up on the
> qpid users mailing list too!!
This seems sensible, although it does raise the question of what is
'dev' about this list if the choice of build system is a 'user' issue!
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Proposal: get rid of automake build system.
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi Alan,
Personally I'd rather cmake was given the heave ho ;->
for all of it's pain automake is something of a defacto standard for a
ton of projects.
Re "Anyone know of specific issues that need to be addressed in cmake?"
yeah, I don't have cmake installed :-D sorry. I'm just messing.
Seriously though I've just reached a point with 0.20 where I didn't have
to hack around with things to get Qpid to compile on my Ubuntu box, so
if I'm honest I'm a little disinclined to change something that finally
works to have things potentially break more again.
If there are strong feelings that agree with your view to move to cmake
can I suggest that deprecation rather than removal of automake is
announced. I think just deleting it from 0.22 is a bit draconian and I
think we should have a couple of releases at least where both exist but
one is marked deprecated so that users get a chance to flag up where
things break (plenty of users only work off official releases - imagine
their surprise if they are forced to use cmake and either they don't
have cmake installed or the cmake breaks for them).
I'm clearly biased 'cause I haven't used cmake, but I'm very anti just
deleting the automake build without a period of it being properly
deprecated.
All that said I do have sympathy with the view that having two build
systems is probably not ideal.
Oh and to follow on a thread that was started a little while back by
Gordon I *really* think that this proposal should be flagged up on the
qpid users mailing list too!!
Frase
On 08/03/13 14:56, Alan Conway wrote:
> Having 2 build systems is a waste of time and a source of confusion.
> We introduced the cmake build with the intent that it would replace
> the automake system, I think the time has come to say farewell to
> automake. The cmake system is ready: it covers the same ground as
> automake and more (esp. windows), and it is actively and successfully
> used by many developers.
>
> I propose that once we have branched for the 0.22 release, we delete
> the automake build system. That will give us plenty of time to find
> and fix any issues with the cmake system before the next release. I'm
> not aware of any major deficiencies in the cmake system, minor
> discrepancies will be quickly found and fixed once everyone has
> switched. I volunteer to help resolve issues that come up.
>
> Are there any strong opinions out there for or against? Anyone know of
> specific issues that need to be addressed in cmake?
>
> Cheers,
> Alan.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
RE: Proposal: get rid of automake build system.
Posted by Steve Huston <sh...@riverace.com>.
+1
I can help with cmake issues as well. I'm not aware of any problems, but the most likely spot is Linux packaging.
> -----Original Message-----
> From: Alan Conway [mailto:aconway@redhat.com]
> Sent: Friday, March 08, 2013 9:57 AM
> To: Qpid Dev
> Subject: Proposal: get rid of automake build system.
>
> Having 2 build systems is a waste of time and a source of confusion. We
> introduced the cmake build with the intent that it would replace the
> automake system, I think the time has come to say farewell to automake.
> The cmake system is ready: it covers the same ground as automake and
> more (esp. windows), and it is actively and successfully used by many
> developers.
>
> I propose that once we have branched for the 0.22 release, we delete the
> automake build system. That will give us plenty of time to find and fix any
> issues with the cmake system before the next release. I'm not aware of any
> major deficiencies in the cmake system, minor discrepancies will be quickly
> found and fixed once everyone has switched. I volunteer to help resolve
> issues that come up.
>
> Are there any strong opinions out there for or against? Anyone know of
> specific issues that need to be addressed in cmake?
>
> Cheers,
> Alan.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org For additional
> commands, e-mail: dev-help@qpid.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org