* Try removing attempt to set the C++ standard
Fixes#1460#1462
* set the standard to 11
* spell it right
* had it right the first time
* require std 11
* plumb through the standard to cxxfeaturecheck
* use policy instead
* can't use policy just yet
* Update CXXFeatureCheck.cmake
* fix CXX_STANDARD_REQUIRED statement
Co-authored-by: Dominic Hamon <dominichamon@users.noreply.github.com>
* Ensure we don't need benchmark installed to pass c++ feature checks
Requires removal of some dependencies on benchmark.h from internal
low-level headers, which is a good thing.
Also added better logging to the feature check cmake module.
* attempt to fix sanitizer builds by moving away from llvm head
* extra verbosity
* try clang 13 and add extra logging
* get latest clang and try again
This slightly prettifies the CMake's `feature_summary()` output,
should the library be built as part of some project that then prints
the CMake summary.
* cmake: fix handling the case where `git describe` fails
* cmake: fix version recorded in releases
If downloaded as a tarball release, there will be no info from git
to determine the release, so it ends up v0.0.0. If that's the case,
we'll now use the release specified in the project() command,
which needs to be updated for each new release.
* cmake: add `--tags` to `git describe`
That way, lightweight tags will also be taken into account, which should
never hurt, but it'll help in cases where, for some mysterious reason or
other, annotated tags don't make it into a clone.
* update releasing.md
* Support optional, user-directed collection of performance counters
The patch allows an engineer wishing to drill into the root causes
of a regression, for example. Currently, only single threaded runs
are supported. The feature is a build-time opt in, and then a runtime
opt in.
The engineer may run the benchmark executable, passing a list of
performance counter names (using libpfm's naming scheme) at the
command line. The counter values will then be collected and reported
back as UserCounters.
This is different from #240 in that it is a benchmark user opt-in, and
the counter collection is transparent to the benchmark.
Currently, this is only supported on platforms where libpfm is
supported.
libpfm: http://perfmon2.sourceforge.net/
* 'Use' values param in Snapshot when BENCHMARK_OS_WINDOWS
This is to avoid unused parameter warning-as-error
* Added missing include for <vector> in perf_counters.cc
* Moved doc to docs
* Added license blurbs
according to https://cmake.org/cmake/help/latest/command/function.html,
"Referencing to ARGV# arguments beyond ARGC have undefined behavior.",
which I hit with cmake 3.19.7.
This uses ARGC to check whether ARGV1 has been passed before referencing
it.
Fixes#974. The `cxx_feature_check` now has an additional
optional argument which can be used to supply extra cmake flags
to pass to the `try_compile` command. The `CMAKE_CXX_STANDARD=14`
flag was determined to be the minimum flag necessary to correctly
compile and run the regex feature checks when compiling with Clang
under Windows (n.b. this does *not* refer to clang-cl, the frontend
to the MSVC compiler). The additional flag is not enabled for any
other compiler/platform tuple.
* ctest is now working
* Update README
* remove commented out lines
* Tweaked docs
Added note to use parallel and cleaned build config notes
* Response to comments
* revert all but the readme
* make error message clearer
* drop --parallel
When cross-compiling, this variable was not set on the second run
of CMake, resulting in the next check failing even though it shouldn't
be run in the first place. Fix this by caching the variable.
In `cmake/GoogleTest.cmake`, GOOGLETEST_PATH is default-initialized, but that init forgot to
account for the fact that the patch is explicitly supposed to be user-configurable.
By passing `CACHE` to `set()` we avoid that error.
https://github.com/google/benchmark/pull/801 is stuck with some cryptic cmake failure due to
some linking issue between googletest and threading libraries.
I suspect that is mostly happening because of the, uhm,
intentionally extremely twisted-in-the-brains approach that is being used to
actually build the library as part of the buiild,
except without actually building it as part of the build.
If we do actually build it as part of the build,
then all the transitive dependencies should magically be in order,
and maybe everything will just work.
This new version of cmake magic was written by me in
0e22f085c5/cmake/Modules/GoogleTest.cmake.in0e22f085c5/cmake/Modules/GoogleTest.cmake, based on the official googletest docs and LOTS of experimentation.
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:
1005485222/cmake/package.pc.in (L13)
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.
* 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.
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.
Git was being executed in the current directory, so could not get the
latest tag if cmake was run from a build directory. Force git to be
run from with the source directory.
Older CMake versions, in particular 2.8, don't seem to correctly handle
interface include directories. This causes failures when building the
tests. Additionally, older CMake versions use a different library install
directory than expected (i.e. they use lib/<target-triple>). This caused
certain tests to fail to link.
This patch fixes both those issues. The first by manually adding the
correct include directory when building the tests. The second by specifying
the library output directory when configuring the GTest build.
* Improve State packing: put important members on first cache line.
This patch does a few different things to ensure commonly accessed
data is on the first cache line of the `State` object.
First, it moves the `error_occurred_` member to reside after
the `started_` and `finished_` bools, since there was internal
padding there that was unused.
Second, it moves `batch_leftover_` and `max_iterations` further up
in the struct declaration. These variables are used in the calculation
of `iterations()` which users might call within the loop. Therefore
it's more important they exist on the first cache line.
Finally, this patch turns the bool members into bitfields. Although
this shouldn't have much of an effect currently, because padding is
still needed between the last bool and the first size_t, it should
help in future changes that require more "bool like" members.
* Remove bitfield change for now
* Move bools (and their padding) to end of "first cache line" vars.
I think it makes the most sense to move the padding required
following the group of bools to the end of the variables we want
on the first cache line.
This also means that the `total_iterations_` variable, which is the
most accessed, has the same address as the State object.
* Fix static assertion after moving bools
We're propagating extra warning flags to the gtest build, which
can cause it to fail. This patch prevents passing "-Wextra" to
gtest, since the library itself doesn't test with that flag.
When users satisfy the GTest dependancy by placing a googletest
directory in the project, the targets from GTest and GMock incorrectly
get installed along side this library. We shouldn't be installing
our test dependancies.
This patch forces the options that control installation for googletest
to OFF.
* Add support for GTest based unit tests.
As Dominic and I have previously discussed, there is some
need/desire to improve the testing situation in Google Benchmark.
One step to fixing this problem is to make it easier to write
unit tests by adding support for GTest, which is what this patch does.
By default it looks for an installed version of GTest. However the
user can specify -DBENCHMARK_BUILD_EXTERNAL_GTEST=ON to instead
download, build, and use copy of gtest from source. This is
quite useful when Benchmark is being built in non-standard configurations,
such as against libc++ or in 32 bit mode.
