1243208 - Reconsider how we're building NSS gtests

Status: NEW

(NSS :: Build, enhancement, P4)

Description

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

In bug 1222665 comment #14, :wtc had concerns about the way we're building gtests, by reaching into ../../cmd for makefiles.

Also, the gtest library itself is using the same makefiles, even though it's a library, which more or less works but probably isn't right.

It's not clear to me that it still makes sense to have "external_tests", now that gtests are more or less a first-class part of the build, and as of bug 1222665 they'll be able to use internal interfaces of the library.

What we really want here is the same build product as the library under test, but with test sources also linked in.  If we stop trying to make the gtests "external", they could live next to the code under test, and the build system could accumulate them and build "with gtests" versions of the libraries — without needing to duplicate whatever special things the library under test needs.

This would especially help with libfreebl and its weird self-recursive build.  I've tried to construct an "external" test that can get at the internals of the freebl shared library, and the result is something that should not land.

Comment 1

[(not currently active) Ted Mielczarek]

Stumbled onto this bug and I was wondering if my gyp patches made this any better. I guess not, really:
https://hg.mozilla.org/users/tmielczarek_mozilla.com/nss/file/06d95803e1d4/external_tests/ssl_gtest/ssl_gtest.gyp#l36

That could probably be fixed to include platlibs.gypi (which is basically a port of platlibs.mk):
https://hg.mozilla.org/users/tmielczarek_mozilla.com/nss/file/06d95803e1d4/cmd/platlibs.gypi

The conversion script I wrote special-cased targets under cmd/ but I didn't notice the usage in external_tests.