qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Proton CMake has just started failing for me
Date Tue, 29 Apr 2014 17:56:55 GMT
On Mon, 2014-04-28 at 15:43 -0400, Rafael Schloming wrote:
> On Mon, Apr 28, 2014 at 3:10 PM, Alan Conway <aconway@redhat.com> wrote:
> 
> > I would expect things to work "out of the box" if I install proton under
> > the same prefix as python/ruby/whatever. I would expect to have to set
> > PYTHONPATH if I install proton somewhere else (are people really
> > confused by that?)
> 
> 
> Yes they are. What confuses people is that when you have /usr/bin/python
> and /usr/local/php, one works "out of the box" and the other doesn't. That
> makes it look like they were both supposed to just work and it gets filed
> as a bug.

Gah! I finally understand what you are getting at. It sucks, but I get
it.

>  I would never expect to set something called
> > SYSINSTALL_BINDINGS and have the installer put some stuff under my
> > prefix and other stuff under /usr, or have a big scary warning in my
> > face suggesting that the software won't work if I don't do so.
> >
> 
> The point of the big scary warning is that the behaviour is changing, not
> that people should feel obliged to use SYSINSTALL_BINDINGS. If you don't
> like it you're free to pretend it doesn't exist. The warning will go away
> for the next release anyways.
> 
> 
> > Agreed that python is a pain with its version numbers in the site-config
> > path but I think we can get rid of SYSINSTALL_BINDINGS, simplify the
> > installer and make everybody happy as follows:
> >
> > 1. install into fixed location <prefix>/<lib>/proton/bindings as we
do
> > already
> > 2. if <prefix>/bin/python exists, also install into it's site-config
> > location. NOTE: *<prefix>*/bin/python NOT /usr/bin/python or whatever
> > python is on the PATH.
> >
> 
> Installing the same files into two locations isn't particularly great,
> however we have already discussed doing (2) via symbolic links.
> 
> I'm pretty opposed to getting rid of SYSINSTALL_BINDINGS though not only to
> avoid spurious bug reports, but also because it is the only foolproof way
> we have to get someone up and running quickly that isn't highly dependent
> on their system configuration. The install instructions are pretty much
> just:
> 
>   cmake SYSINSTALL_BINDINGS=ON
>   make
>   sudo make install
> 
> Having this level of simplicity is A) quite useful for people who just want
> to try things out and B) makes it a lot simpler to test in a wide variety
> of different environments. If you can come up with build behaviour that
> facilitates a README that is as simple or simpler than the above then I'd
> be happy to kill SYSINSTALL_BINDINGS.
> 

Gahhh! I can't. I'll keep trying. However I do think that if people
don't use SYSINSTALL_BINDINGS then we should respect the <prefix>, as I
proposed above. E.g. suppose I
have /usr/bin/python, /usr/local/bin/python and I do

cmake CMAKE_INSTALL_PREFIX=/usr/local
make
sudo make install

The we can and should install under /usr/local...site-config regardless
of what is in the PATH. If SYSINSTALL_BINDINGS is specified then we go
for the PATH.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message