On Mon, 2014-04-28 at 13:41 -0400, Rafael Schloming wrote: > On Mon, Apr 28, 2014 at 12:25 PM, Alan Conway <[email protected]> wrote: > > > On Mon, 2014-04-28 at 10:44 -0400, Andrew Stitcher wrote: > > > On Sat, 2014-04-26 at 16:25 +0100, Fraser Adams wrote: > > > > ... > > > > Also could someone please explain the reason for the change around the > > > > "SYSINSTALL_BINDINGS is unspecified" stuff? Why make the default > > > > behaviour do something that "will no longer be found by system > > > > interpreters. This means that every user will be required to manually > > > > configure their interpreters to locate the proton bindings". Clearly > > > > -DSYSINSTALL_BINDINGS=ON will make it behave like it used to do, but > > why > > > > change that from the default? It might be good if the text is modified > > > > to say *why* this is no longer the default, 'cause it seems kind of > > odd. > > > > > > This is a long running dispute between some project members (they know > > > who they are). > > > > > > Essentially the Proton behaviour has changed to match the qpid > > > behaviour. > > > > > > Previously it would (try to) install in places that weren't in the > > > install prefix (but that were where the cmake detected language > > > interpreter said its modules should go), now it needs the > > > SYSINSTALL_BINDINGS flag to do this. > > > > > > There are various reasons for the different positions - I will let those > > > who feel more strongly in one direction of the other advocate for their > > > position. > > > > Let me try. > > > > The previous behavior is WRONG. If you specify an install prefix you > > must never randomly install files under /usr just because that's the > > default python interpreter's sys.prefx!!! The whole point of specifying > > a different install prefix is to keep your installation separate from > > the /usr stuff, which is probably managed by rpm, yum, apt or whatever > > and requires root privileges. There's an ancient and well known > > mechanism for handling stuff not installed under /usr: set PATH, > > PYTHONPATH and LD_LIBRARY_PATH. > > > > The SYSINSTALL_BINDINGS is attempting to fix this obvious brokenness but > > in an unnecessarily clumsy way. You should *always* install files in the > > same place *relative to the install prefix*. I.e. if the prefix > > is /usr/local, you should install python bits in the standard python > > place *relative to usr/local*. If the prefix is /usr you should install > > them in the standard place *relative to /usr*. You shouldn't need an > > extra SYSINSTALL_BINDINGS variable to tell you this. > > > > Therefore there should be only one variable that you need to fiddle > > with: CMAKE_INSTALL_PREFIX. If you set it to /usr then everything gets > > installed in the standard place under /usr, which is usually the > > standard place for the built-in python interpreter. There shouldn't be a > > need for SYSINSTALL_BINDINGS. If you set it to some other place > > (e.g. /usr/local) then everything should get installed in the *same* > > place but relative to /usr/local. > > > > Not sure why this is causing so much confusion. > > > > The problem is there may be more than one interpreter. Say you have ruby or > php installed under /usr/local and python installed under /usr, then there > is no possible CMAKE_INSTALL_PREFIX you can supply that will get both of > them to work "out of the box". This leads to people being confused and > reporting the "fixed place relative to install prefix" behaviour as broken. > > And to be clear, the build currently does by default exactly what you're > suggesting. It installs all the bindings in a fixed location relative to > the specified install prefix. The SYSINSTALL_BINDINGS parameter simply > gives you the option of installing into the locations specified by the > system interpreters if that is what you wish to do. > > --Rafael
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?) 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. 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. This way: - if you install into /usr it Just Works, installing in the /usr..site-config as you'd like. - if you install somewhere else, e.g. /usr/local that has python installed it Just Works with /usr/local/bin/python and nothing gets installed outside the prefix. - if you install somewhere other than where python is installed, then you have to set PYTHONPATH. That's not surprising is it? Cheers, Alan. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
