You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by Phil Harvey <ph...@philharveyonline.com> on 2013/01/30 15:53:17 UTC
proton bindings installation paths
I've been looking at where "make install" writes files to, and came across
something that seems like a wrinkle. I'd like to get views on whether it's
worth fixing.
You can control the destination of most files using the
CMAKE_INSTALL_PREFIX property. However, it looks like the bindings
CMakeLists.txt files don't respect this.
For example, the Python bindings are installed to wherever the Python
expression "get_python_lib" evaluates to. It looks like the Perl bindings
use a similarly non-overrideable location.
This is a minor irritation because I'd like to test "make install" without
affecting shared folders under /usr. I'll raise a Jira to fix this...
unless there are any objections?
Cheers,
Phil
Re: proton bindings installation paths
Posted by Phil Harvey <ph...@philharveyonline.com>.
Thanks Darryl, that makes sense.
Phil
On 30 January 2013 15:00, Darryl L. Pierce <dp...@redhat.com> wrote:
> On Wed, Jan 30, 2013 at 02:53:17PM +0000, Phil Harvey wrote:
> > I've been looking at where "make install" writes files to, and came
> across
> > something that seems like a wrinkle. I'd like to get views on whether
> it's
> > worth fixing.
> >
> > You can control the destination of most files using the
> > CMAKE_INSTALL_PREFIX property. However, it looks like the bindings
> > CMakeLists.txt files don't respect this.
> >
> > For example, the Python bindings are installed to wherever the Python
> > expression "get_python_lib" evaluates to. It looks like the Perl
> bindings
> > use a similarly non-overrideable location.
> >
> > This is a minor irritation because I'd like to test "make install"
> without
> > affecting shared folders under /usr. I'll raise a Jira to fix this...
> > unless there are any objections?
>
> We had a discussion on the list a while back about this topic [1]. The
> decision was that we would install language bindings into locations
> specified by the individual language environments. If you want to
> install things to a separate location, you need to set the DESTDIR
> variable when running "making install" in order to install the entire
> set to an alternate location.
>
> [1]
>
> http://mail-archives.apache.org/mod_mbox/qpid-proton/201212.mbox/%3CJIRA.12623970.1355492653982.7193.1355492773169@arcas%3E
>
> --
> Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
> Delivering value year after year.
> Red Hat ranks #1 in value among software vendors.
> http://www.redhat.com/promo/vendor/
>
>
Re: proton bindings installation paths
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Wed, Jan 30, 2013 at 02:53:17PM +0000, Phil Harvey wrote:
> I've been looking at where "make install" writes files to, and came across
> something that seems like a wrinkle. I'd like to get views on whether it's
> worth fixing.
>
> You can control the destination of most files using the
> CMAKE_INSTALL_PREFIX property. However, it looks like the bindings
> CMakeLists.txt files don't respect this.
>
> For example, the Python bindings are installed to wherever the Python
> expression "get_python_lib" evaluates to. It looks like the Perl bindings
> use a similarly non-overrideable location.
>
> This is a minor irritation because I'd like to test "make install" without
> affecting shared folders under /usr. I'll raise a Jira to fix this...
> unless there are any objections?
We had a discussion on the list a while back about this topic [1]. The
decision was that we would install language bindings into locations
specified by the individual language environments. If you want to
install things to a separate location, you need to set the DESTDIR
variable when running "making install" in order to install the entire
set to an alternate location.
[1]
http://mail-archives.apache.org/mod_mbox/qpid-proton/201212.mbox/%3CJIRA.12623970.1355492653982.7193.1355492773169@arcas%3E
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/