[jira] [Updated] (MESOS-2096) Allow Mesos modules to be built outside the Mesos source tree

["Kapil Arya (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/MESOS-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kapil Arya updated MESOS-2096:
------------------------------
    Description: 
We want to be able to provide a mechanism to allow third parties to build Mesos modules outside the Mesos source tree.  Ideally, we would want to build Mesos modules without the need to build Mesos itself, provided that the public headers and corresponding shared libraries are available.

Building a Mesos module requires access to the following components:
1. stout headers
2. libprocess headers and corresponding dynamic libraries (current, just libmesos.so)
3. protobufs
4. glog
5. gmock/gtest (optional)
6. boost

Of the above components, stout headers and libprocess headers are already installed as part of standard Mesos installation.

The problem lies with the bundled packages such as protobufs.  It is the understanding that Mesos modules should be built with the same version of these packages with which Mesos was built.  Since Mesos may have used the bundled versions, there is no way to build a module without having access to the Mesos source tree and the build directory.

Having access to the source and build directory solves only part of the problem.  The module build system needs to be aware of the configure parameters that were used for building Mesos (and accordingly, the bundled packages).  A hackish solution is to force Mesos build system to emit the necessary information in a format that can be consumed by the module build system.

A better solution is to remove the bundled packages -- protobuf, gmock, boost, and glog -- from the Mesos distribution and instead rely on system provided packages.  Since these packages are usually available on most distros, we just need to do a  configure check in Mesos and fail if they are not installed.

Once these dependencies are resolved, we can export the header files defining module "kinds" such as  isolator.hpp, authenticator.hpp, etc.  At this point, there won't any known blockers that could prevent building modules out of Mesos tree.

  was:
We want to be able to provide a mechanism to allow third parties to build Mesos modules outside the Mesos source tree.  Ideally, we would want to build Mesos modules without the need to build Mesos itself, provided that the public headers and corresponding shared libraries are available.

Building a Mesos module requires access to the following components:
1. stout headers
2. libprocess headers and corresponding dynamic libraries (current, just libmesos.so)
3. protobufs
4. glog
5. gmock/gtest (optional)
6. boost

Of the above components, stout headers and libprocess headers are already installed as part of standard Mesos installation.

The problem lies with the bundled versions of protobufs, etc.  It is the understanding that Mesos modules should be built with the same version of these packages with which Mesos was built.  Since Mesos may have used the bundled versions, there is no way to build a module without having access to Mesos source tree and the build directory.

Having access to the build directory solves only part of the problem.  The module build system needs to be aware of the bundled packages that were used for building Mesos.  A hackish solution is to force Mesos build system to emit the necessary information in a format that can be consumed by the module build system.

A better solution is to remove the bundled packages protobuf, gmock, boost, and glog from Mesos distribution and instead rely on system provided packages.  Since these packages are usually available on most distros, we just need to do a  configure check in Mesos and fail if they are not installed.

Once these dependencies are resolved, we can export the file defining module "kinds" such as  isolator.hpp, authenticator.hpp, etc.  At this point, there won't any known blockers that could prevent building modules out of Mesos tree.


> Allow Mesos modules to be built outside the Mesos source tree
> -------------------------------------------------------------
>
>                 Key: MESOS-2096
>                 URL: https://issues.apache.org/jira/browse/MESOS-2096
>             Project: Mesos
>          Issue Type: Bug
>            Reporter: Kapil Arya
>            Priority: Blocker
>
> We want to be able to provide a mechanism to allow third parties to build Mesos modules outside the Mesos source tree.  Ideally, we would want to build Mesos modules without the need to build Mesos itself, provided that the public headers and corresponding shared libraries are available.
> Building a Mesos module requires access to the following components:
> 1. stout headers
> 2. libprocess headers and corresponding dynamic libraries (current, just libmesos.so)
> 3. protobufs
> 4. glog
> 5. gmock/gtest (optional)
> 6. boost
> Of the above components, stout headers and libprocess headers are already installed as part of standard Mesos installation.
> The problem lies with the bundled packages such as protobufs.  It is the understanding that Mesos modules should be built with the same version of these packages with which Mesos was built.  Since Mesos may have used the bundled versions, there is no way to build a module without having access to the Mesos source tree and the build directory.
> Having access to the source and build directory solves only part of the problem.  The module build system needs to be aware of the configure parameters that were used for building Mesos (and accordingly, the bundled packages).  A hackish solution is to force Mesos build system to emit the necessary information in a format that can be consumed by the module build system.
> A better solution is to remove the bundled packages -- protobuf, gmock, boost, and glog -- from the Mesos distribution and instead rely on system provided packages.  Since these packages are usually available on most distros, we just need to do a  configure check in Mesos and fail if they are not installed.
> Once these dependencies are resolved, we can export the header files defining module "kinds" such as  isolator.hpp, authenticator.hpp, etc.  At this point, there won't any known blockers that could prevent building modules out of Mesos tree.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)