[
https://issues.apache.org/jira/browse/PROTON-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13824619#comment-13824619
]
Justin Ross 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.
"""
That's pretty unattractive. It means that anyone wishing to do install
everything to a prefix will need to do something like this:
cmake -D CMAKE_INSTALL_PREFIX:TEXT=/opt -D
RUBY_INSTALL_DIR:TEXT=/opt/lib/ruby/... -D
PERL_INSTALL_DIR:TEXT=/opt/lib/perl/... -D
PYTHON_INSTALL_DIR:TEXT=/opt/lib/python/...
And keep going for each new binding language. Really?
"""
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.
"""
Why is that a goal? An install prefix is intended to prefix *everything*--I
mean, I'm at a loss: that's literally its reason for being. That's precisely
what I'm trying to use it for.
Warning: the current behavior is going to result in users accidentally
overwriting their distro-installed files. Consider what 'sudo make install'
will do on a system that already has proton packages installed.
> 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
> CMAKE_INSTALL_PREFIX
> 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
(v6.1#6144)
