src/gtest/ contains a copy of dev-cpp/gtest-1.5.0
It has been debated weather this is a bug with the package since it's the (stupid) recommended model by upstream.
(In reply to Thomas Kahle from comment #1) > It has been debated weather this is a bug with the package since it's the > (stupid) recommended model by upstream. hey, @thomas 1) any link of that debate? 2) any sane solution we can present for upstream (personally I feel it's difficult to persuade upstream when come to bundled libraries, kind of painful) checked latest version 0.72.2, problem still there.. I thought we could at least make it optional depend on bundled libraries, but after checking the code, it's hardcoded to internal gtest ./src/Makefile.in:1018: $(top_builddir)/src/gtest/lib/libgtest_main.a \ ./src/Makefile.in:3253:DIST_SUBDIRS = gtest ocf libs3 java ./src/Makefile.in:4268: -I$(top_srcdir)/src/gtest/include \ ./src/Makefile.in:4269: -I$(top_builddir)/src/gtest/include ./src/Makefile.in:4272: $(top_builddir)/src/gtest/lib/libgtest.a \ ./src/Makefile.in:4273: $(top_builddir)/src/gtest/lib/libgtest_main.a \ ./src/test/utf8.cc:15:#include "gtest/gtest.h" ./src/test/librbd/test_librbd.cc:25:#include "gtest/gtest.h" ./src/test/base64.cc:20:#include "gtest/gtest.h" ./src/test/run_cmd.cc:4:#include "gtest/gtest.h" ./src/test/simple_spin.cc:1:#include "gtest/gtest.h" ./src/test/cls_hello/test_cls_hello.cc:20:#include "gtest/gtest.h" ./src/test/test_texttable.cc:17:#include "gtest/gtest.h" ./src/test/perf_counters.cc:30:#include "gtest/gtest.h" ./src/test/test_rgw_admin_opstate.cc:43:#include <gtest/gtest.h> ./src/test/bufferlist.cc:33:#include "gtest/gtest.h" ./src/test/bufferlist.cc:2016:// compile-command: "cd .. ; make unittest_bufferlist ; ulimit -s unlimited ; CEPH_BU FFER_TRACK=true valgrind --max-stackframe=20000000 --tool=memcheck ./unittest_bufferlist # --gtest_filter=BufferLis t.constructors" ./src/test/cls_replica_log/test_cls_replica_log.cc:11:#include "gtest/gtest.h" ./src/test/ceph_argparse.cc:17:#include "gtest/gtest.h" ./src/test/test_rgw_admin_log.cc:42:#include <gtest/gtest.h> ./src/test/cls_rbd/test_cls_rbd.cc:11:#include "gtest/gtest.h" ./src/test/test_filejournal.cc:2:#include <gtest/gtest.h> ./src/test/libcephfs_config.cc:15:#include "gtest/gtest.h" ./src/test/test_snap_mapper.cc:14:#include "gtest/gtest.h" ./src/test/cls_version/test_cls_version.cc:8:#include "gtest/gtest.h" ./src/test/encoding.cc:5:#include "gtest/gtest.h" ./src/test/mon/moncap.cc:20:#include "gtest/gtest.h" ./src/test/ceph_compatset.cc:32:#include "gtest/gtest.h" ./src/test/test_stress_watch.cc:9:#include "gtest/gtest.h" ./src/test/test_workqueue.cc:1:#include "gtest/gtest.h" ./src/test/cls_rgw/test_cls_rgw.cc:7:#include "gtest/gtest.h" ./src/test/mime.cc:15:#include "gtest/gtest.h" ./src/test/libcephfs/readdir_r_cb.cc:15:#include "gtest/gtest.h" ./src/test/libcephfs/test.cc:15:#include "gtest/gtest.h" ./src/test/libcephfs/caps.cc:16:#include "gtest/gtest.h" ./src/test/libcephfs/multiclient.cc:15:#include "gtest/gtest.h" ./src/test/test_striper.cc:1:#include "gtest/gtest.h" ./src/test/Makefile.am:244: -I$(top_srcdir)/src/gtest/include \ ./src/test/Makefile.am:245: -I$(top_builddir)/src/gtest/include ./src/test/Makefile.am:247: $(top_builddir)/src/gtest/lib/libgtest.a \
Here are two opinions on the matter http://thread.gmane.org/gmane.linux.gentoo.devel/86486/focus=86641 I personally think Google's statement as to why gtest should be bundled doesn't apply to Gentoo. We have very precise control over which version of gtest was built with which flags, but it's not entirely foolproof: the user could first build gtest, then change compiler flags, then build a dependency and it may trigger a false positive. The matter is undecided. I would suggest the upstream devs to bundle gtest. It's very lightweight and not installed on the users's system. In this sense it is not a "bundled library" as we know it.
I don't think unbundling gtest/gmock is worth it, since it is not used at runtime, only at src_test time (and given this package is current RESTRICT=test ...) I had a look at the submodules list, afaics the only other 3rd party libraries that are bundled are jerasure and gf-complete. Unbundling of libraries that are co-developed by ceph upstream seems kind of pointless to me, unless there are other users in the tree.
What about #463326, shouldn't be add as depended bug?
(In reply to Marcin Mirosław from comment #5) > What about #463326, shouldn't be add as depended bug? This _is_ bug #463326
Lol! Too many tabs in browser:) I try once more. What about bug #560020, should be added to this bug or resolved as duplicate of this bug?
seems also to be bundling boost and libzstd
It's also bundling thrift
