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
