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
> # 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.
> 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