Packaging mesos
David Gilman
davidgilman1 at gmail.com
Mon Nov 19 16:59:06 UTC 2018
Mesos is a ginormous C++ codebase that does distributed execution of
user tasks. I have a functioning but basic portfile here. I also have
a bunch of questions on MacPorts policy and what it will take to get a
mesos port accepted. Here is my portfile:
# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil;
c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
PortSystem 1.0
PortGroup cxx11 1.1
name mesos
version 1.7.0
categories devel
platforms darwin
maintainers {@dgilman gilslotd.com:dgilman} openmaintainer
license Apache-2
homepage https://mesos.apache.org/
master_sites apache:mesos/${version}
description Apache Mesos abstracts CPU, memory, storage, and
other compute resources \
away from machines (physical or virtual), enabling
fault-tolerant \
and elastic distributed systems to easily be built
and run effectively.
long_description ${description}
checksums rmd160 28a10cb2975657034fadd0b5da6ff2b9498564d5 \
sha256
0d02700eafef0af07f2257537eb164a3fd31b6cae291e0d025335f5333acd8bf \
size 69737576
configure.args-append --with-svn=${prefix} \
--with-apr=${prefix} \
--disable-werror \
--disable-python \
--disable-java \
--disable-maintainer-mode
depends_lib port:apr-util \
port:subversion
build.env MAVEN_OPTS=-Duser.home=${workpath}/.home
I have the Java and Python libraries (APIs into mesos) disabled to
simplify the build, but it also seems that it might not be possible to
use the Python library at all because of a weird incompatibility with
modern versions of pip.
Mesos ships with many vendored 3rd party libraries. There are 21
.tar.gz files in ./3rdparty. Many of them are distributed with
macports but some have not yet been packaged. When mesos is built a
single, gigantic dylib is made that incorporates all of this code
(none of these libraries are shipped with mesos):
otool -L /opt/local/bin/mesos
/opt/local/bin/mesos:
/opt/local/lib/libmesos-1.7.0.dylib (compatibility version 0.0.0,
current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1252.50.4)
/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current
version 1.2.11)
/opt/local/lib/libsvn_delta-1.0.dylib (compatibility version 1.0.0,
current version 1.0.0)
/opt/local/lib/libsvn_subr-1.0.dylib (compatibility version 1.0.0,
current version 1.0.0)
/opt/local/lib/libsasl2.dylib (compatibility version 3.0.0, current
version 3.0.0)
/opt/local/lib/libcurl.4.dylib (compatibility version 10.0.0, current
version 10.0.0)
/opt/local/lib/libapr-1.0.dylib (compatibility version 7.0.0, current
version 7.3.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
otool -L /opt/local/lib/libmesos-1.7.0.dylib
/opt/local/lib/libmesos-1.7.0.dylib:
/opt/local/lib/libmesos-1.7.0.dylib (compatibility version 0.0.0,
current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1252.50.4)
/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current
version 1.2.11)
/opt/local/lib/libsvn_delta-1.0.dylib (compatibility version 1.0.0,
current version 1.0.0)
/opt/local/lib/libsvn_subr-1.0.dylib (compatibility version 1.0.0,
current version 1.0.0)
/opt/local/lib/libsasl2.dylib (compatibility version 3.0.0, current
version 3.0.0)
/opt/local/lib/libcurl.4.dylib (compatibility version 10.0.0, current
version 10.0.0)
/opt/local/lib/libapr-1.0.dylib (compatibility version 7.0.0, current
version 7.3.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
Is this acceptable for MacPorts, or does mesos need to be built with
MP's distribution of libraries? The mesos ./configure has options to
use local versions of these libraries: boost, concurrentqueue, elfio,
glog, gmock, grpc, http-parser, jemalloc, leveldb, libev, libevent,
libarchive, nvml, picojson, rapidjson, protobuf, sasl, ssl, stout,
zookeeper, nl. It also might be possible to ignore all vendored
package with a ./configure --disable-bundled flag and force all of the
vendored packages into MacPorts dependency handling and packaging. I
would appreciate some feedback on the MP policy here.
Finally, it seems like mesos is a little trigger happy when it comes
to installing these 3rd party libraries to the build root. I had
issues with it installing its own bundled versions of
pip/wheel/setuptools but it looks like that might be fixable. The
portfile above also installs C/C++ header files for elfio, picojson,
libprocess, rapidjson and stout alongside mesos. Is it OK for a
Portfile to do this?
For reference, Homebrew's distribution always builds with java
libraries (and has a dependency on java 1.8 or greater), it has a hack
to install the Python client library by itself and it uses the
vendored dependencies as much as possible.
--
David Gilman
:DG<
More information about the macports-dev
mailing list