qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: Proposal: get rid of automake build system.
Date Sat, 09 Mar 2013 09:24:42 GMT
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


Mime
View raw message