README: make test won't work before gtest is built

[SigmaX]

Since we include gtest as a submodule, building tests is easy and convenient.

But the README suggests that building the tests is as simple as running make test after checkout. This won't work until gtest has been built—that that takes a few steps.

We should update the README to direct users to the gtest README, and to build the gtest library in the designated path.

[mbeyeler]

Good point. We can probably link to User Guide Ch.11: Regression Suite for more info, where I explained how to install gtest for our purposes, but the README instructions are confusing. In fact, Ch.1 of the User Guide makes the same mistake.

[mbeyeler]

Just had another confused user contact me. Need to do this asap.

[mbeyeler]

An alternative would be to have make test automatically compile gtest if needed (i.e., run the cmake recipe as part of make test).

[vuw-ecs-kevin]

When you do come to document this, could you also
consider making sure a know version of the googletest
code, and maybe other external codes goes into
the "release" tarballs, for those people who want a
known point in the code to work from, rather than
multiple people working from their own constantly
changing sync of a constantly changing repo?

Just had a research group here telling me that they are
going to be using CARLsim over the summer (in NZ)
and when I downloaded the 3.1.3 tarball, so as to "get
ahead of the game", I hit the same problems in trying to
follow the install instructions, but, having then found this
issue, I then found that the extra instructions from the 'User
Guide Ch.11: Regression Suite' are of little use, because the

external/googletest

dir, despite exsiting in the "release" tarball payload is empty.

Here's hoping,
Kevin M. Buckley

eScience Consultant
School of Engineering and Computer Science
Victoria University of Wellington
New Zealand

[mbeyeler]

Hi Kevin,

Thanks for bringing this to our attention. After some googling, I found GitHub's official answer to this is that submodules are never included in releases:

This is not possible currently.
Thanks for the suggestion though! I have added it to our list for our team to consider.

However, to address your concern, we do already tag the 3.1.3 release to a specific commit of each external library - meaning that everyone checking out CARLsim 3.1.3 with a recursive clone will also get the same googletest version (which I believe is currently set at 1.7.0).

$ git clone --recursive https://github.com/YourUsername/CARLsim3
$ cd CARLsim3
$ git checkout v3.1.3

Best,
Michael

[vuw-ecs-kevin]

However, to address your concern, we do already tag the 3.1.3 release to a specific commit
of each external library - meaning that everyone checking out CARLsim 3.1.3 with a recursive
clone will also get the same googletest version (which I believe is currently set at 1.7.0).

OK, that's really useful to know, Michael, cheers.

If that kind of thing ("You will need googletest v 1.7.0") was documented
in the release tarballs, then I could have gone straight to the tagged
release UR for the external packageI:

https://github.com/google/googletest/releases/tag/release-1.7.0

which is a lot simpler to remember than that commit ID.

Cheers again,
Kevin

[vuw-ecs-kevin]

So i downloaded the 1.7.0 googletest tarball, unpacked it at
placed the contents at /path/to/CARLsim3-3.1.3/external/googletest

When I now make test I get some errors akin to this one

In file included from external/googletest/include/gtest/gtest.h:58:0,
                 from carlsim/test/conn_mon.cpp:1:
carlsim/test/conn_mon.cpp: In member function 'virtual void ConnMon_weightFile_Test::TestBody()':
carlsim/test/conn_mon.cpp:323:22: error: no match for 'operator!=' (operand types are 'std::ifstream {aka std::basic_ifstream<char>}' and 'int')
    EXPECT_TRUE(wtFile!=0);
                ~~~~~~^~~
                ~~~~~~^~~
external/googletest/include/gtest/internal/gtest-internal.h:1111:34: note: in definition of macro 'GTEST_TEST_BOOLEAN_'
       ::testing::AssertionResult(expression)) \
                                  ^~~~~~~~~~
carlsim/test/conn_mon.cpp:323:4: note: in expansion of macro 'EXPECT_TRUE'
    EXPECT_TRUE(wtFile!=0);
    ^~~~~~~~~~~
carlsim/test/conn_mon.cpp:323:22: note: candidate: operator!=(int, int) <built-in>
    EXPECT_TRUE(wtFile!=0);
                ~~~~~~^~~
external/googletest/include/gtest/internal/gtest-internal.h:1111:34: note: in definition of macro 'GTEST_TEST_BOOLEAN_'
       ::testing::AssertionResult(expression)) \
                                  ^~~~~~~~~~
carlsim/test/conn_mon.cpp:323:4: note: in expansion of macro 'EXPECT_TRUE'
    EXPECT_TRUE(wtFile!=0);
    ^~~~~~~~~~~
carlsim/test/conn_mon.cpp:323:22: note:   no known conversion for argument 1 from 'std::ifstream {aka std::basic_ifstream<char>}' to 'int'
    EXPECT_TRUE(wtFile!=0);
                ~~~~~~^~~
external/googletest/include/gtest/internal/gtest-internal.h:1111:34: note: in definition of macro 'GTEST_TEST_BOOLEAN_'
       ::testing::AssertionResult(expression)) \
                                  ^~~~~~~~~~
carlsim/test/conn_mon.cpp:323:4: note: in expansion of macro 'EXPECT_TRUE'
    EXPECT_TRUE(wtFile!=0);
    ^~~~~~~~~~~

...

which, in looking around on the interweb thing, suggests possible
solutions along these lines

• https://stackoverflow.com/questions/9753842/googletest-fails-to-use-custom-comparison-operator
• https://stackoverflow.com/questions/33371088/how-to-get-a-custom-operator-to-work-with-google-test

but those soultions suggest an issue to be addressed within the test code,
not in the external googletest code.

So, have you seen, or had anything like that reported ?

FWIW, we have GCC 6.3.1 here.