[gentoo-dev] dev-cpp/gtest

[gentoo-dev] dev-cpp/gtest

[Thomas Kahle]

[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

Hi,

dev-cpp/gtest is Google's testing framework.  According to upstream it
is supposed to be shipped as source code and then compiled by the build
system of the software that should be tested.  In particular it should
be compiled with exactly the same flags.

So far our gtest package has shipped only the compiled library and a
bunch of helper scripts.  Now bug 474454 asks for the sources to be
installed too (or exclusively).  What should we do?

a) Drop the library from the ebuild and break most of the consumers who
don't follow upstreams recommendation.
b) Install shared library and sources giving maintainers the choice to
follow upstreams instructions or not.

Here's a list of packages that have gtest in their deps:

app-i18n/librime
app-i18n/mozc
app-text/dvisvgm
dev-cpp/glog
dev-cpp/gmock
dev-cpp/pficommon
dev-games/aseprite
dev-libs/msgpack
dev-util/ninja
dev-util/open
kde-misc/socket
media-libs/audiofile
media-libs/chromaprint
sci-libs/flann
sci-libs/trilinos
sys-apps/paludis

Cheers,
Thomas


-- 
Thomas Kahle


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: [gentoo-dev] dev-cpp/gtest

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]

On 6/30/13 3:03 PM, Thomas Kahle wrote:
> dev-cpp/gtest is Google's testing framework.  According to upstream it
> is supposed to be shipped as source code and then compiled by the build
> system of the software that should be tested.  In particular it should
> be compiled with exactly the same flags.

That's correct, and I consider that design broken.

They could have easily provided an executable like gtest-config or even
just use pkg-config to provide proper flags to compile the dependent
sources.

> So far our gtest package has shipped only the compiled library and a
> bunch of helper scripts.  Now bug 474454 asks for the sources to be
> installed too (or exclusively).  What should we do?

IMHO a package that installs sources makes no sense. Anything that would
use it would be highly non-standard - this was not indended to be shared.

I'd rather schedule dropping the package and make reverse dependencies
use bundled gtest (upstream intends this to be used as a copylib).

In the long term it could be worth it to convince upstream to do
something more sane and standard. It is technically possible.

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

[gentoo-dev] Re: dev-cpp/gtest

[Steven J. Long]

Thomas Kahle wrote:
> So far our gtest package has shipped only the compiled library and a
> bunch of helper scripts.  Now bug 474454 asks for the sources to be
> installed too (or exclusively).  What should we do?
> 
> a) Drop the library from the ebuild and break most of the consumers who
> don't follow upstreams recommendation.
> b) Install shared library and sources giving maintainers the choice to
> follow upstreams instructions or not.

a) The packages are broken in any case, if they don't use gtest files
bundled during build, but rely on an external at runtime instead. Break em
and let them get fixed, is better than shouldering the maintenance burden of
accommodating stupidity. No one will thank you for it in any case, and nothing
will improve, but your life will be harder.

There isn't really any point in trying to install this separately in any case.
That is not its intended usage at all.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)