Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.5
    • Fix Version/s: 0.7
    • Component/s: proton-c
    • Labels:
      None

      Description

      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:

      1. cmake -DCMAKE_INSTALL_PREFIX:PATH=/opt/myplace /var/tmp/jross/baker/proton/source
      2. 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.

        Issue Links

          Activity

          Hide
          ASF subversion and git services added a comment -

          Commit 1571719 from Darryl L. Pierce in branch 'proton/trunk'
          [ https://svn.apache.org/r1571719 ]

          PROTON-445: Dynamic languages honor CMAKE_INSTALL_PREFIX

          All languages are installed to $CMAKE_INSTALL_PREFIX/bindings/$LANG by
          default.

          If the ASK_ALL macro is set to 1 at the command line, then each
          language is interrogated as to the location of where they will be
          installed, and that path modified wit the install prefix.

          Individual languages can be told to interrogate for the install path
          with:

          ASK_[LANG]=1

          Show
          ASF subversion and git services added a comment - Commit 1571719 from Darryl L. Pierce in branch 'proton/trunk' [ https://svn.apache.org/r1571719 ] PROTON-445 : Dynamic languages honor CMAKE_INSTALL_PREFIX All languages are installed to $CMAKE_INSTALL_PREFIX/bindings/$LANG by default. If the ASK_ALL macro is set to 1 at the command line, then each language is interrogated as to the location of where they will be installed, and that path modified wit the install prefix. Individual languages can be told to interrogate for the install path with: ASK_ [LANG] =1
          Hide
          ASF subversion and git services added a comment -

          Commit 1547834 from Darryl L. Pierce in branch 'proton/trunk'
          [ https://svn.apache.org/r1547834 ]

          Revert "PROTON-445: Python install now honors CMAKE_INSTALL_PREFIX"

          This reverts commit e9557788a0098de4d6ec3e201fb0f53596e211c7.

          Show
          ASF subversion and git services added a comment - Commit 1547834 from Darryl L. Pierce in branch 'proton/trunk' [ https://svn.apache.org/r1547834 ] Revert " PROTON-445 : Python install now honors CMAKE_INSTALL_PREFIX" This reverts commit e9557788a0098de4d6ec3e201fb0f53596e211c7.
          Hide
          ASF subversion and git services added a comment -

          Commit 1547833 from Darryl L. Pierce in branch 'proton/trunk'
          [ https://svn.apache.org/r1547833 ]

          Revert "PROTON-445: Perl install now honors CMAKE_INSTALL_PREFIX"

          This reverts commit 17a0b3b5cb46301e40b2082f6c5316a0876422c1.

          Show
          ASF subversion and git services added a comment - Commit 1547833 from Darryl L. Pierce in branch 'proton/trunk' [ https://svn.apache.org/r1547833 ] Revert " PROTON-445 : Perl install now honors CMAKE_INSTALL_PREFIX" This reverts commit 17a0b3b5cb46301e40b2082f6c5316a0876422c1.
          Hide
          ASF subversion and git services added a comment -

          Commit 1547831 from Darryl L. Pierce in branch 'proton/trunk'
          [ https://svn.apache.org/r1547831 ]

          Revert "PROTON-445: PHP install now honors the install prefix."

          This reverts commit 395e4e3d3892639db126d7d8011c784f5aaae381.

          Show
          ASF subversion and git services added a comment - Commit 1547831 from Darryl L. Pierce in branch 'proton/trunk' [ https://svn.apache.org/r1547831 ] Revert " PROTON-445 : PHP install now honors the install prefix." This reverts commit 395e4e3d3892639db126d7d8011c784f5aaae381.
          Hide
          ASF subversion and git services added a comment -

          Commit 1547597 from Darryl L. Pierce in branch 'proton/trunk'
          [ https://svn.apache.org/r1547597 ]

          PROTON-445: PHP install now honors the install prefix.

          If the install prefix is not "/usr" then the INI directory is placed
          below it. This is to accomodate a system install as opposed to a
          developer install.

          Show
          ASF subversion and git services added a comment - Commit 1547597 from Darryl L. Pierce in branch 'proton/trunk' [ https://svn.apache.org/r1547597 ] PROTON-445 : PHP install now honors the install prefix. If the install prefix is not "/usr" then the INI directory is placed below it. This is to accomodate a system install as opposed to a developer install.
          Hide
          ASF subversion and git services added a comment -

          Commit 1547578 from Darryl L. Pierce in branch 'proton/trunk'
          [ https://svn.apache.org/r1547578 ]

          PROTON-445: Perl install now honors CMAKE_INSTALL_PREFIX

          The language bindings will now honor this prefix, both the default
          value and a user-specified value.

          Developers can override it, though, by specifying PERL_INSTALL_PREFIX
          at the command line as well. This will allow for installing the Perl
          bindings to a different directory if so desired.

          Also updated the installation pieces in CMake to simplify it.

          Show
          ASF subversion and git services added a comment - Commit 1547578 from Darryl L. Pierce in branch 'proton/trunk' [ https://svn.apache.org/r1547578 ] PROTON-445 : Perl install now honors CMAKE_INSTALL_PREFIX The language bindings will now honor this prefix, both the default value and a user-specified value. Developers can override it, though, by specifying PERL_INSTALL_PREFIX at the command line as well. This will allow for installing the Perl bindings to a different directory if so desired. Also updated the installation pieces in CMake to simplify it.
          Hide
          ASF subversion and git services added a comment -

          Commit 1547577 from Darryl L. Pierce in branch 'proton/trunk'
          [ https://svn.apache.org/r1547577 ]

          PROTON-445: Python install now honors CMAKE_INSTALL_PREFIX

          The language bindings will now honor this prefix, both the default value
          and a user-specified value.

          Developers can override it, though, by specifying PYTHON_INSTALL_PREFIX
          at the command line as well. This will allow for installing the Python
          bindings to a different directory if so desired.

          Show
          ASF subversion and git services added a comment - Commit 1547577 from Darryl L. Pierce in branch 'proton/trunk' [ https://svn.apache.org/r1547577 ] PROTON-445 : Python install now honors CMAKE_INSTALL_PREFIX The language bindings will now honor this prefix, both the default value and a user-specified value. Developers can override it, though, by specifying PYTHON_INSTALL_PREFIX at the command line as well. This will allow for installing the Python bindings to a different directory if so desired.
          Hide
          Darryl L. Pierce added a comment -

          In playing with various environment systems like RVM, I think there's a workable solution that'll honor the CMAKE_INSTALL_PREFIX while not requiring extra effort. So I'll withdraw my objections before. Sorry for the distraction.

          Show
          Darryl L. Pierce added a comment - In playing with various environment systems like RVM, I think there's a workable solution that'll honor the CMAKE_INSTALL_PREFIX while not requiring extra effort. So I'll withdraw my objections before. Sorry for the distraction.
          Hide
          Darryl L. Pierce added a comment -

          CMAKE_INSTALL_PREFIX is always defined; i.e., there is never a run of Cmake where it's not a defined variable. So my question would be what should the default install behavior be for language bindings if no CMAKE_INSTALL_PREFIX is specified in the command line? Should the Ruby, Perl and Python bindings install under /usr/local or to the site packages location for that language? We can't depend on CMAKE_INSTALL_PREFIX to tell us what there user wants WRT the language bindings since it's always present.

          That's why I suggested individual language paths for users who want to override them. For someone who uses RVM for Ruby development, or Virtual Environment for Python, they would want to be able to install the language binding to their virtual environment's location but not the whole Proton codebase there. RVM defaults to putting your Ruby versions under $HOME/.rvm/environments and VE puts them under any arbitrary directory where the user chooses. If CMAKE_INSTALL_PREFIX trumps the Ruby VM then the user would have to do some extra work to switch environments.

          Show
          Darryl L. Pierce added a comment - CMAKE_INSTALL_PREFIX is always defined; i.e., there is never a run of Cmake where it's not a defined variable. So my question would be what should the default install behavior be for language bindings if no CMAKE_INSTALL_PREFIX is specified in the command line? Should the Ruby, Perl and Python bindings install under /usr/local or to the site packages location for that language? We can't depend on CMAKE_INSTALL_PREFIX to tell us what there user wants WRT the language bindings since it's always present. That's why I suggested individual language paths for users who want to override them. For someone who uses RVM for Ruby development, or Virtual Environment for Python, they would want to be able to install the language binding to their virtual environment's location but not the whole Proton codebase there. RVM defaults to putting your Ruby versions under $HOME/.rvm/environments and VE puts them under any arbitrary directory where the user chooses. If CMAKE_INSTALL_PREFIX trumps the Ruby VM then the user would have to do some extra work to switch environments.
          Hide
          Justin Ross added a comment -

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

          Show
          Justin Ross added a comment - """ 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.
          Hide
          Darryl L. Pierce added a comment -

          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.

          Show
          Darryl L. Pierce added a comment - 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.
          Hide
          Justin Ross added a comment -

          The attached output shows three different combinations of install prefix and destdir. For me, none of the outcomes are the desired one.

          Show
          Justin Ross added a comment - The attached output shows three different combinations of install prefix and destdir. For me, none of the outcomes are the desired one.

            People

            • Assignee:
              Darryl L. Pierce
              Reporter:
              Justin Ross
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development