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