mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Till Toenshoff (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (MESOS-1071) Enable building against installed third-party dependencies.
Date Tue, 25 Mar 2014 00:43:43 GMT

    [ https://issues.apache.org/jira/browse/MESOS-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13945915#comment-13945915
] 

Till Toenshoff edited comment on MESOS-1071 at 3/25/14 12:41 AM:
-----------------------------------------------------------------

We seem to have reached a point where decisions are needed. Personally, I am not attached
to the details of the current implementation. My goal is open the path to a mesos source distribution
that is mostly free of bundles.

Let me try to gather all demands that were expressed on this feature;
a. allow users to specify the intend to generally use system provided libs instead of bundled
b. make sure that dependencies that are installed in a standard location are recognized without
the user having to specify their path
c. allow users to specify the installation path of a dependency
d. make sure that individual dependencies can be enabled to use preinstalled or bundled versions

re a. introduced {{--disable-bundled}} which generally tries to avoid bundled resources, but
when system installed versions could not be located, would fall back to the bundled version
(while displaying a warning).
re b. see a.
re c. introduced {{--with-XYZ=DIR}} which specifically tries to recognize a dependency at
the given location, but when such version could not be located, would error-out.
re d. has not been fully addressed by my RR as the user that wants to disable individual bundled
versions, will have to supply a full path unless he/she uses (a).

1. Which name should be used for that {{disable-bundled}} / {{enable-proper}} switch?
Tim is not too attached to a specific name. Adam has come to the conclusion that {{with(out)-system-dependencies}}
would fit best.

2. Do we want auto-fallback when a user asked for {{disable-bundled}} / {{enable-proper}}?

Tim has provided a very good reason to say no to such fallback: package-maintainers are simply
not allowed to bundle.
 
3. As (d) is an unaddressed requirement, but mostly addressed in {{without-bundled-zookeeper}},
shall we adopt this for all dependencies?
This would lead to verbose configuration options; {{with-zookeeper=DIR}} for a non standard
location, {{without-included-zookeeper}} for a standard location. Both could be combined into
{{without-included-zookeeper[=DIR]}} but that does not seem to be very intuitive, no?

Please try to use this JIRA for general / functional request changes and not the comments
on the RR itself to allow us having a well documented conclusion history in one place.


was (Author: tillt):
We seem to have reached a point where decisions are needed. Personally, I am not attached
to the details of the current implementation. My goal is open the path to a mesos source distribution
that is mostly free of bundles.

Let me try to gather all demands that were expressed on this feature;
a. allow users to specify the intend to generally use system provided libs instead of bundled
b. make sure that dependencies that are installed in a standard location are recognized without
the user having to specify their path
c. allow users to specify the installation path of a dependency
d. make sure that individual dependencies can be enabled to use preinstalled or bundled versions

re a. introduced {{--disable-bundled}} which generally tries avoid bundled resources, but
when system installed versions could not be located, would fall-back to the bundled version
(while displaying a warning).
re b. see a.
re c. introduced {{--with-XYZ=DIR}} which specifically tries to recognize a dependency at
the given location, but when such version could not be located, would error-out.
re d. has not been fully addressed by my RR as the user that wants to disable individual bundled
versions, will have to supply a full path unless he/she uses (a).

1. Which name should be used for that {{disable-bundled}} / {{enable-proper}} switch?
Tim is not too attached to a specific name. Adam has come to the conclusion that {{with(out)-system-dependencies}}
would fit best.

2. Do we want auto-fallback when a user asked for {{disable-bundled}} / {{enable-proper}}?

Tim has provided a very good reason to say no to such fallback: package-maintainers are simply
not allowed to bundle.
 
3. As (d) is an unaddressed requirement, but mostly addressed in {{without-bundled-zookeeper}},
shall we adopt this for all dependencies?
This would lead to verbose configuration options; {{with-zookeeper=DIR}} for a non standard
location, {{without-bundled-zookeeper}} for a standard location. Both could be combined into
{{without-bundle-zookeeper[=DIR]}} but that does not seem to be very intuitive, no?

Please try to use this JIRA for general / functional request changes and not the comments
on the RR itself to allow us having a well documented conclusion history in one place.

> Enable building against installed third-party dependencies.
> -----------------------------------------------------------
>
>                 Key: MESOS-1071
>                 URL: https://issues.apache.org/jira/browse/MESOS-1071
>             Project: Mesos
>          Issue Type: Improvement
>          Components: build
>            Reporter: Benjamin Hindman
>         Attachments: modified_tillt.patch
>
>
> Most of our third-party dependencies are included in the project and statically linked
into our resulting binaries and libraries. We would like to enable building Mesos but using
system installed dependencies instead.
> In certain circumstances this is more difficult because we've actually needed to "patch"
these libraries (either for C++11 or to alter semantics).
> Rather than eliminating our internal copies of these third-party dependencies the first
step should be to just enable using external (i.e., system installed) dependencies. We already
do this for ZooKeeper by allowing people to use the --without-included-zookeeper flag during
compilation. We should do this for other libraries as well. In fact, for the libraries that
we have not patched (and even for some that we have patched) we should check to see if an
appropriate system installed dependency exists and preferentially use that unless --with-included-dependency
is explicitly used.
> Note that this issue represents a stepping stone to removing our third-party dependencies
from our repository.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message