mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Peach <>
Subject Re: Install some 3rdparty packages needed for building Mesos modules
Date Wed, 27 Jan 2016 04:21:25 GMT

> On Jan 26, 2016, at 10:54 AM, Kapil Arya <> wrote:
> Thanks for the feedback, Alex! I have inlined my responses.
>> First, I think we should support two use cases: installing 3rdparty
>> packages and exposing them in the local build. As a Mesos (module)
>> developer, I may have different versions of Mesos on my machine and I
>> install neither of them to avoid conflicts. If I develop a module for a
>> particular Mesos version (i.e. build), I would like to use artifacts of
>> that build without installing them anywhere.
> That's a valid use case. How about "installing" the 3rdparty packages
> by setting their $PREFIX to $(top_builddir)/3rdparty? That way, one
> can append "-I$(top_builddir)/3rdparty/include" to CPPFLAGS and
> "$(top_builddir)/3rdparty/lib" to their LD_LIBRARY_PATH when building
> modules? We can also update libprocess/Mesos to also use these
> locations instead of passing a dozen "-I" and "-L" flags during
> compilation. I am guessing this won't be too intrusive to the overall
> build system.
>> Second, additionally 3rdparty packages, how about modules we provide with
>> Mesos, e.g. FixedResourceEstimator? Also if in the future we decide to
>> refactor default implementations into modules (e.g. hierarchical
>> allocator), we should install them somewhere.
> We have a ticket (
> for it :-). We should just install them in $(pkglibdir).

My changes in MESOS-3608 install them into a new directory $pkgmoduledir based on review feedback.
$pkgmoduledir is $pkglibdir/modules. My patch installs compatibility symlinks from $libdir
for people who have configuration using the existing modules.

> That's the
> default location for distro packaging as well. That's not too hard to
> do. Just that we need to decide which modules should be installed.
> Best,
> Kapil
>> On Wed, Jan 20, 2016 at 8:09 AM, Kapil Arya <> wrote:
>>> On Wed, Jan 20, 2016 at 2:04 AM, Marco Massenzio <>
>>> wrote:
>>>> Great thinking, Kapil!
>>>> (I'm one who got the headache :)
>>>> However, having recently gone through the effort of having to figure out
>>> it
>>>> all, my +1 goes for *good documentation* of what is necessary.
>>> Totally with you on this :)
>>>> When installing stuff / magic happening behind the scenes, it is always
>>>> difficult to ensure it works on all "supported" platforms (and let's not
>>>> even go into non-supported ones) and we would also run the risk that
>>> future
>>>> changes may inadvertently break it.
>>>> Bear also in mind that folks (who may not be using the --prefix) may be
>>>> "surprised" to find incompatible/unexpected versions of
>>> glog/protobuf/etc.
>>>> in the /usr/local system dir.
>>> This is the reason why we want to put it inside Mesos "owned"
>>> directories (e.g., /usr/local/include/mesos/3rdparty,
>>> /usr/lib64/mesos/3rdparty) so that this whole operation is side-effect
>>> free for other applications/packages installed on the system.
>>>> We could also provide "exemplary scripts" that automate (most of) the
>>>> tedious work and example build files, alongside documentation.
>>>> If folks agree that this is a desirable alternative, I'm happy to help
>>> out
>>>> - as mentioned, I've recently been through this, so memory is still
>>> fresh.
>>> I think several of us have developed such scripts by now. However, the
>>> problem is maintainability as they get out-of-sync whenever a 3rdparty
>>> component is updated in Mesos :-/.
>>>> My 2c.
>>>> --
>>>> *Marco Massenzio*
>>>> On Tue, Jan 19, 2016 at 10:22 PM, Kapil Arya <>
>>> wrote:
>>>>> On Tue, Jan 19, 2016 at 11:58 PM, James Peach <>
>>>>>>> On Jan 19, 2016, at 2:03 PM, Kapil Arya <>
>>>>>>> Hi All,
>>>>>>> I wanted to get your opinion on installing the 3rdparty packages
>>> glog,
>>>>>>> protobuf, boost and picojson[1] when installing Mesos itself.
>>>>>>> packages are required to build Mesos modules.
>>>>>> An alternative approach could be to hide these headers so they are
>>>>> internal to Mesos and not incidentally required by innocent modules.
>>> IIRC
>>>>> this should be fairly easy for picojson, but (much) harder for glog,
>>>>> protobuf and boost.
>>>>> That's a lot of work and super hard to maintain IMHO :(.
>>>>>>> Currently, a module write has to manually install these 3rdparty
>>>>>>> packages, either system-wide or locally, and update the compilation
>>>>>>> flags such as CPPFLAGS to point to the installation which is
>>>>>>> error-prone. Further, one might have a system-wide installation
>>>>>>> the wrong package version, causing even more headache.
>>>>>> If you are looking at this, could you please also look at these:
>>>>>> MESOS-2537 provides consistent behaviour for building against
>>> optionally
>>>>> bundled dependencies (and fixes the --enable-foo semantics).
>>>>> I'll take a look at this one.
>>>>>> MESOS-4096 makes it impossible to run stout tests against a protobuf
>>>>> that is not version 2.5.0.
>>>>> At some point, AlexR and I tried to work on it, but with the stout
>>>>> directory structure, it got harder to fix then it seemed at first.
>>>>>>> The proposal here is to install these 3rdparty packages when
>>>>>>> installing Mesos. To avoid any conflicts with system-wide or
>>>>>>> installation, we can install them as follows:
>>>>>>> ${PREFIX}/include/mesos/3rdparty -- for header files
>>>>>>> ${PREFIX}/<LIBDIR>/mesos/3rdparty -- for library files
(LIBDIR can be
>>>>>>> lib or lib64 depending upon the installation)
>>>>>>> where PREFIX refers to the `--prefix` flag for Mesos configure
>>> script.
>>>>>>> We would then update `mesos.pc` with the correct flags so that
>>>>>>> module write can simply use `pkg-config` to get all the required
>>>>>>> flags.
>>>>>>> I have created an issue
>>>>>>> to track this.
>>>>>>> Best,
>>>>>>> Kapil
>>>>>>> [1]: picojson is currently installed in ${PREFIX}/include. See

View raw message