qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darryl L. Pierce" <dpie...@redhat.com>
Subject Re: Dynamic language install and CMAKE_INSTALL_PREFIX
Date Thu, 05 Dec 2013 19:29:07 GMT
On Thu, Dec 05, 2013 at 01:57:22PM -0500, Rafael Schloming wrote:
<snip> 
> 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.

I find the simplicity in this scenario to be very attractive. It also
avoids situations like what I saw with the PHP ini directory location,
to use project-defined directories for defaults.

What I've seen, for each of the language bindings, is a need to know:

 1. the directory to install platform-independent modules,
 2. the directory to install platform-specific modules, and
 3. the directory to install configuration (PHP only)

So perhaps ${LANG}_LIBDIR, ${LANG}_ARCHDIR and ${LANG}_CONFDIR? In an
RPM specfile we could define each one using the provide language's macro
and it would be a fairly easy integration point. And if you don't define
them then they work as you suggest above.

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

+1

-- 
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/


Mime
View raw message