Darryl L. Pierce commented on PROTON-445:

Another suggestion, if we're to override where each language wants extensions 
installed, would be to have binding-specific variables (RUBY_INSTALL_DIR, 
PERL_INSTALL_DIR, PYTHON_INSTALL_DIR) that can be overridden by the developer 
if needed. By default the value for each variable would be what's returned by 
the language but which can be overridden individually.

Also, if we used CMAKE_INSTALL_PREFIX, how would the developer specifically say 
_not_ to apply it to their binding installations? If they want to install 
Proton to /opt but have their language bindings go to the default place the 
build system wouldn't be able to differentiate.

> Binding installation ignores prefix
> -----------------------------------
>                 Key: PROTON-445
>                 URL: https://issues.apache.org/jira/browse/PROTON-445
>             Project: Qpid Proton
>          Issue Type: Bug
>          Components: proton-c
>    Affects Versions: 0.5
>            Reporter: Justin Ross
>         Attachments: what-a-mess.txt
> It allows you *prepend* to the install prefix, but it gives you no way afaict 
> to actually change the prefix.
> This is the opposite of nice.  If you set a prefix for your build *and* you 
> try to get your bindings slotted in with them, via DESTDIR, you get this:
> # cmake -DCMAKE_INSTALL_PREFIX:PATH=/opt/myplace 
> /var/tmp/jross/baker/proton/source
> # make install DESTDIR=/opt/myplace
> /opt/myplace/usr/lib/python/*python files*
> /opt/myplace/opt/myplace/lib/*c files*
> ^^ Note "/opt/myplace/opt/myplace", the first from DESTDIR, the second from 
> What it is doing now is simply abuse of DESTDIR.  DESTDIR is intended to be a 
> mechanism for staged installs (packaging systems use this), and it cannot 
> function correctly as an override for prefix.
> http://www.gnu.org/prep/standards/html_node/DESTDIR.html
> My proposed solution to this is to stop this madness: make the binding 
> install honor CMAKE_INSTALL_PREFIX.  Let the developer be responsible for 
> choosing the right location for his or her distribution.

This message was sent by Atlassian JIRA

Reply via email to