[
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)
