On 02.10.2016 01:34, Daniel Stender wrote: > I've now spend a couple of hours working on packaging Mesos 1.0.1. There are > several problems > using Debian packages instead of the libraries vendored/bundled in 3rdparty/. > > The config system provides switches like --with-boost, --with-gmock, > --with-glock etc., but: > > 1) for Boost they developers are using "-isystem" instead of "-I" imports for > the CPPFLAGS > to easily overcome some problems > (https://issues.apache.org/jira/browse/MESOS-3932), but > -isystem makes problems for the other imports: > > <buildlog> > {...} -c gmock_sources.cc -fPIC -DPIC -o .libs/libgmock_la-gmock_sources.o > In file included from /usr/include/c++/6/ext/string_conversions.h:41:0, > from /usr/include/c++/6/bits/basic_string.h:5402, > from /usr/include/c++/6/string:52, > from /usr/include/c++/6/bits/locale_classes.h:40, > from /usr/include/c++/6/bits/ios_base.h:41, > from /usr/include/c++/6/ios:42, > from /usr/include/c++/6/ostream:38, > from gmock-1.7.0/gtest/include/gtest/gtest.h:55, > from gmock-1.7.0/gtest/src/gtest-all.cc:39, > from gmock_sources.cc:18: > /usr/include/c++/6/cstdlib:75:25: fatal error: stdlib.h: No such file or > directory > </buildlog> > > see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129 (stdlib.h: No such > file or directory when using -isystem /usr/... ) > > 2) the gmock import paths are not working out of the box with the > google-gmock package: > > --with-gmock=/usr: > > <buildlog> > checking gmock-all.cc usability... no > checking gmock-all.cc presence... no > checking for gmock-all.cc... no > configure: error: cannot find gmock > ------------------------------------------------------------------- > You have requested the use of a non-bundled gmock but no suitable > gmock could be found. > </buildlog> > > it should be going something like: > > <diff> > --- a/configure.ac > +++ b/configure.ac > @@ -808,12 +808,12 @@ AM_CONDITIONAL([WITH_BUNDLED_GLOG], > [test "x$with_bundled_glog" = "xyes"]) > > -GMOCKSRC="gmock-all.cc" > +GMOCKSRC="src/gmock-all.cc" > GTESTSRC="gtest-all.cc" > > if test -n "`echo $with_gmock`"; then > CPPFLAGS="$CPPFLAGS -I${with_gmock} -I${with_gmock}/include \ > - -I${with_gmock}/src -I${with_gmock}/gtest -I${with_gmock}/gtest/include \ > + -I${with_gmock}/src/gmock -I${with_gmock}/gtest > -I${with_gmock}/gtest/include \ > -I${with_gmock}/gtest/src" > > elif test "x$enable_bundled" != "xyes"; then > </diff> > > The same for the libgtest-dev imports. That could be solved, however > > 3) the vendored package 3rdparty/nvml-352.79.tar.gz contains solely > nvidia/gdk/nvml.h, but that > appears not be DFSG-free. > > 4) libelfio and picojson are both RFP (#839382, #773325), these could be > packaged by, but > > 5) the upstream tarball ships own patches for several of the vendored > 3rdparts tarballs, like > for glog 0.3.3, http-parser 2.6.2 (needs to be updated in Debian, #795492), > leveldb 1.4, libev 4.22, > protobuf 2.6.1, zookeeper 3.4.8. Some libraries like libprocess are forked in > own 3rdparty (belonging > to Mesos) repositories on Github (like > https://github.com/3rdparty/libprocess). I haven't checked > it closer so far, but it could be that there are many things which aren't > (supposed to being?) integrated > into the other projects. > > I haven't given up, but I'm not so sure if there could be solutions for all > of the points above if > not wanted to ship most of the convenience packages with a mile long > deb/copyright and just putting the > thing into non-free because of (yet) a single file. > > DS
... towards 5), https://github.com/3rdparty/glog is a better example, libprocess isn't a fork. DS -- 4096R/DF5182C8 http://www.danielstender.com/blog/
signature.asc
Description: OpenPGP digital signature
