It broke because the libc++ is being built as part of *this*
build, with old gcc+libstdc++ (4.8?), but LLVM is preparing
to switch to C++14, and gcc+libstdc++ <5 are soft-deprecated.

Just the gcc update doesn't cut it, clang still uses old libstdc++.

Created BenchmarkName class which holds the full benchmark
name and allows specifying and retrieving different components
of the name (e.g. ARGS, THREADS etc.)

Fixes #730.

Refs #779.

Run into this by accident while writing benchmark to validate
the fix for https://bugs.llvm.org/show_bug.cgi?id=40965

Fixes #779.

- On qnx platform, cpu and cache info is stored in a syspage struct which
  is different from other OS platform.
- The fix has been verified on an aarch64 target running qnx 7.0.
Fixes #774

Since googletest already supports x-compilation for QNX, it is nice to
 have google benchmark support it too.
Fixes #766

Since pthread is required at least for GCC (according to the
documentation), this should be reflected by the pkg-config file.

The same is, for instance, also done by the gflags library:
https://github.com/gflags/gflags/blob/1005485222e8b0feff822c5723ddcaa5abadc01a/cmake/package.pc.in#L13

Commit 17a012d7 added a newline to the str, so the line built from
str.length() is one character longer than it should be.

If this policy isn't set, CMake emits a large warning when project() is
called from a cmake subdirectory.

This came up when the benchmark library was added to the LLVM build, and
it was reported in https://llvm.org/PR38874. This patch was the fix I
applied locally to fix the issue, and I wanted to send it upstream.

Some benchmarks are particularly sensitive and they run in less than
a nanosecond. In order for the console reporter to provide meaningful
output for such benchmarks it needs to be able to display the times
using more resolution than a single nanosecond.

This patch changes the console reporter to print at least three
significant digits for all results.

Unlike the initial attempt, this patch does not align the decimal point.

As pointed out in IRC, these are not documented.

It should now match reality.

* Adding Host Name and test

* Addressing Review Comments

* Adding Test for JSON Reporter

* Adding HOST_NAME_MAX for MacOS systems

* Adding Explaination for MacOS HOST_NAME_MAX Addition

* Addressing Peer Review Comments

* Adding codecvt in windows header guard

* Changing name SystemInfo and adding empty message incase host name fetch fails

* Adding Comment on Struct SystemInfo

Unit-tests fail to build due to the following errors:

/home/cfx/Dev/google-benchmark/benchmark.git/test/string_util_gtest.cc:12:5: required from here
/home/cfx/Applications/googletest-1.8.1/include/gtest/gtest.h:1444:11: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
   if (lhs == rhs) {
       ~~~~^~~~~~

Fixes #741

std::tmpnam is deprecated and its use is discouraged. For our purposes
in the tests, we really just need a file name which is unlikely to
exist.

This patch converts the tests to using a dummy random file name
generator, which should hopefully avoid name conflicts.

Fixes #714.

Used that example as a snippet, and it took a moment to notice
what needed to be changed to make it compile..

This is the copy of patch proposed to LLVM's copy of benchmark via
https://reviews.llvm.org/D52998.

s390 has another line structure for processor-field.
It should be differently parsed.

It is incorrect to say that an aggregate is computed over
run's iterations, because those iterations already got averaged.
Similarly, if there are N repetitions with 1 iterations each,
an aggregate will be computed over N measurements, not 1.
Thus it is best to simply use the count of separate reports.

Fixes #586.

It is better to let the RunBenchmarks(), report() decide
whether to actually *only* output aggregates or not,
depending on whether there are actually aggregates.

It's subtle indeed.

Previously, `BenchmarkRunner()` always said that "if there are no repetitions,
then you should never output only the repetitions". And the `report()` simply assumed
that the `report_aggregates_only` bool it received makes sense, and simply used it.

Now, the logic is the same, but the blame has shifted.
`BenchmarkRunner()` always propagates what those benchmarks would have wanted
to happen wrt the aggregates. And the `report()` lambda has to actually consider
both the `report_aggregates_only` bool, and it's meaningfulness.

To put it in the context of the patch series - if the repetition count was `1`,
but `*_report_aggregates_only` was set to `true`, and we capture each iteration separately,
then we will compute the aggregates, but then output everything, both the iteration,
and aggregates, despite `*_report_aggregates_only` being set to `true`.

That is the real purpose of that bool. A follow-up change will
make it consider something else other than repetitions.

If benchmark added as cmake subproject, HandleGTest throws an error as  does return absolute source dir.
Change it to , so it will be refering to it's own source dir.

Also see PR #703. 

This reverts commit 60975230.

* Fix SOURCE_DIR in HandleGTest.cmake

If benchmark added as cmake subproject, HandleGTest throws an error as  does return absolute source dir.
Change it to , so it will be refering to it's own source dir.

As prevously written, "--benchmark_color=auto" was treated as true,
because IsTruthyFlagValue("auto") returned true.  The fix is to
rely on IsColorTerminal test only if the flag value is "auto",
and fall back to IsTruthyFlagValue otherwise.  I also integrated
force_no_color check into the same block.

For several versions now, CMake by default refers to macOS’ Clang as AppleClang instead of just Clang, which would fail STREQUAL. Fixed by changing it to MATCHES.

Ok, so, i'm still trying to get to the state when it will be a trivial change to report all the separate iterations.
The old code (LHS of the diff) was rather convoluted i'd say.
I have tried to refactor it a bit into *small* logical chunks, with proper comments.
As far as i can tell, i preserved the intent of the code, what it was doing before.
The road forward still isn't clear, but i'm quite sure it's not with the old code :)