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 Mon, 28 Apr 2014 16:25:54 GMT
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,

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.

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

View raw message