As I understand it, the following process is roughly what we're going
through for each binding to determine possible/actual install locations:
1. Query the (python/perl/ruby/php/...) interpreter to find the appropriate
directory that is in the interpreters search path by default, e.g.
site-packages for python. Let's call this the QUERIED_LOCATION.
2. Modify the QUERIED_LOCATION by substituting the CMAKE_INSTALL_PREFIX for
the interpreter's own install prefix. Let's call this the
CONSTRUCTED_LOCATION.
3. In the case where {LANG}_INSTALL_PREFIX is specified, step (2) is
modified to substitute {LANG}_INSTALL_PREFIX rather than
CMAKE_INSTALL_PREFIX. Let's call this the CUSTOM_LOCATION.
Just in case things aren't clear from above, here are some example values
for python:
Example 1: CMAKE_INSTALL_PREFIX=/usr/local
===========================
QUERIED_LOCATION=/usr/lib64/python2.6/site-packages
CONSTRUCTED_LOCATION=/usr/local/lib64/python2.6/site-packages
CUSTOM_LOCATION=*N/A*
Example 2: CMAKE_INSTALL_PREFIX=/usr, PYTHON_INSTALL_PREFIX=/usr/local
===========================
QUERIED_LOCATION=/usr/lib64/python2.6/site-packages
CONSTRUCTED_LOCATION=/usr/lib64/python2.6/site-packages
CUSTOM_LOCATION=/usr/local/lib64/python2.6/site-packages
Example 3: CMAKE_INSTALL_PREFIX=/home/rhs/proton,
PYTHON_INSTALL_PREFIX=/home/rhs/modules
===========================
QUERIED_LOCATION=/usr/lib64/python2.6/site-packages
CONSTRUCTED_LOCATION=/home/rhs/proton/lib64/python2.6/site-packages
CUSTOM_LOCATION=/home/rhs/modules/lib64/python2.6/site-packages
The existing trunk behaviour is to simply use the QUERIED_LOCATION
directly. This will place installed code where it will be found by
precisely the interpreter it was built against without any users being
required to set up custom search paths. This has a number of benefits and a
couple of drawbacks also.
The primary benefit is that the build will adapt itself to the user's
environment. If the user has some custom python/ruby interpreter in their
path, it will configure and built itself against it and get the user up and
running right away. This makes for a very simple and idiot proof README for
someone wanting to get up and running quickly from a source build, and for
much the same reason it is also very handy for testing. I depend on it
myself quite a bit since I have a number of differently configured VMs that
I use for install testing, and for each one I can simply log in and use the
same incantation and be confident I'm running/testing the code that I
expect. There is also a second order testing benefit since having a dirt
simple and robust build option lets us give a source tarball to other
people to test easily and not have to explain to them how to set up custom
search paths for each language before they can get bootstrapped into
running test code.
The drawbacks that have been pointed out are that when you do specify a
CMAKE_INSTALL_PREFIX, it is unintuitive for things to be placed outside
that prefix, and this can happen if the QUERIED_LOCATION for a given
interpreter happens to be outside the specified prefix. It's also been
pointed out that if you happen to have an rpm installed version of proton
then with the existing trunk behaviour you could could end up accidentally
overwriting it since rpm installs proton code into the QUERIED_LOCATION
also.
Based on my reading, the change you've pointed to removes the ability to
install directly to the QUERIED_LOCATION and instead uses the
CONSTRUCTED_LOCATION. It also adds a consistent control interface for
providing a custom location, i.e. the {LANG}_INSTALL_PREFIX variables.
Assuming I've read this correctly, I have the following comments.
First, I'm not ok with losing the ability to install directly to the
queried location. I don't mind if it's not the default, but I want a simple
and easy way to get back that behaviour as it is of significant value in
the scenarios I've mentioned above.
Second, I think it's important to realize that the CONSTRUCTED_LOCATION is
almost guaranteed to be meaningless and quite possibly harmful if it is at
all different from the QUERIED_LOCATION. To understand this you can take a
look at the values from example 1 above. The queried interpreter is the
system interpreter installed under /usr, but the binding code is installed
under /usr/local. In the best case scenario, this code will never be found
because nothing under /usr/local is in the default python search path. In
the worst case scenario there may be other python interpreters installed
under /usr/local that will find and attempt to load the code but will fail
because the code was built against a differently configured python (the
python version could be different, or it could even be the same version but
with a different build configuration).
Third, the custom location doesn't actually give you full control over
where the module is installed because it appends a portion of the queried
location. This strikes me as the wrong thing to do in all the scenarios I
can think of where you'd want to supply a custom location. For instance, in
Example 3 above, I might have my python path already pre-configured to
search in /home/rhs/modules for stuff to load, however there is no way for
me to tell the build to install the binding there, if I supply that it will
end up going under /home/rhs/modules/lib64/python2.6/site-packages. The
other scenario I can think of here is doing an rpm build, and in that case
you'd want to directly pass in the %{python_sitelib} macro which will
already include the lib64/python2.6/site-packages portion.
So overall I'd say this change should have some kind of switch to control
whether the QUERIED_LOCATION is used directly, and I'd argue that for the
CUSTOM_LOCATION we should just pass through directly what the user supplies
and not attempt to merge it with the queried value. As for the
CONSTRUCTED_LOCATION, it's worth noting that we don't necessarily need to
compute that either, we could just pick an arbitrary location, e.g.
${CMAKE_INSTALL_PREFIX}/lib64/proton-bindings or some such thing.
Wherever we end up, we should also probably abstract the behaviour into a
macro so that the behaviour is easier to keep consistent between bindings,
and so that new bindings pick up the same behaviour automatically.
--Rafael
On Wed, Dec 4, 2013 at 11:13 AM, Darryl L. Pierce <dpie...@redhat.com>wrote:
> I have a proposed changeset [1] to meet this request (they were pushed,
> but after a discussion this morning I've reverted the changes) and want
> to get feedback on it before changing the default behavior for Proton.
>
> Currently no language binding honors the CMAKE_INSTALL_PREFIX path. So,
> if your current Ruby keeps its vendor extensions in
> /usr/share/ruby/vendor_ruby, then if you set CMAKE_INSTALL_PREFIX to
> /var/tmp/foo, the bindings won't isntall there.
>
> With the changes I'm proposing, the build environment asks the language
> for 1) the install prefix for directories and then 2) the directory for
> vendor extensions. It then does a string substition, replacing the
> install prefix in the directory with the CMAKE_INSTALL_PREFIX value
> provided.
>
> For power users, there's a way to override this by specifying, for each
> language, a different install prefix only for that language. So, for
> example, you could pass in RUBY_INSTALL_PREFIX to have the build
> environment use that instead of CMAKE_INSTALL_PREFIX.
>
> I'd like to get more input from others who use the dynamic languages as
> to whether this approach finds a good middle ground for what everybody
> expects when installing and using Proton.
>
> [1] http://reviews.apache.org/r/16004/
>
> --
> 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/
>
>
