qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <...@alum.mit.edu>
Subject Re: Dynamic language install and CMAKE_INSTALL_PREFIX
Date Thu, 05 Dec 2013 19:41:53 GMT
On Thu, Dec 5, 2013 at 2:29 PM, Darryl L. Pierce <dpierce@redhat.com> wrote:

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

Sounds good to me. We could also use one for docs. The python bindings have
documentation, and hopefully the other bindings will eventually need
somewhere for docs as well.

--Rafael


>
> > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message