openwrt/upstream - upstream openwrt

	Commit message (Expand)	Author	Age	Files	Lines
*	tools/sstrip: update to latest version	Rui Salvaterra	2020-11-26	3	-472/+36
*	tools/sstrip: add PKG_{VERSION,RELEASE}	Paul Spooren	2020-07-23	1	-0/+2
*	tools/sstrip: Fix compile under standard linux.	Rosen Penev	2017-12-08	1	-4/+5
*	tools: remove static linking support	Jo-Philipp Wich	2015-02-06	1	-1/+1
*	tools/sstrip: remove redundant -I flag that breaks build on some x86_64 linux...	Felix Fietkau	2012-12-02	1	-1/+1
*	sstrip: remove a redundant copy of elf.h	Felix Fietkau	2012-12-02	2	-2446/+1
*	use HOST_STATIC_LINKING instead of hardcoding -static	Jo-Philipp Wich	2012-08-12	1	-1/+1
*	sstrip: link statically	Jo-Philipp Wich	2012-08-10	1	-2/+2
*	tools: clean up Makefiles / make ccache work	John Crispin	2012-01-15	1	-1/+1
*	Revert "[tools] sstrip: Correct include path to really get endian.h" (#8447)	Florian Fainelli	2010-12-12	1	-1/+1
*	sstrip: Correct include path to really get endian.h	Daniel Dickinson	2010-12-12	1	-1/+1
*	Revert "[tools] sstrip: Was missing include of <byteswap.h>"	Daniel Dickinson	2010-12-12	1	-1/+0
*	sstrip: Was missing include of <byteswap.h>	Daniel Dickinson	2010-12-12	1	-0/+1
*	sstrip: fix a section length corruption bug (patch from #6847)	Felix Fietkau	2010-03-12	1	-2/+1
*	build system refactoring in preparation for allowing packages to do host-buil...	Felix Fietkau	2009-02-22	1	-5/+5
*	fix sstrip compile on mac os x	Felix Fietkau	2007-12-02	1	-1/+1
*	build system cleanup/restructuring as described in http://lists.openwrt.org/p...	Felix Fietkau	2007-08-07	1	-11/+3
*	host-build.mk used incorrectly	Mike Baker	2007-05-10	1	-1/+2
*	fix missing PKG_NAME	Felix Fietkau	2006-12-06	1	-0/+1
*	cleanup	Felix Fietkau	2006-10-14	2	-26/+1
*	finally move buildroot-ng to trunk	Felix Fietkau	2016-03-20	3	-0/+2967

If you cannot find the answer to your question here, and you have read [Primer](V1_6_Primer.md) and [AdvancedGuide](V1_6_AdvancedGuide.md), send it to googletestframework@googlegroups.com. ## Why should I use Google Test instead of my favorite C++ testing framework? ## First, let us say clearly that we don't want to get into the debate of which C++ testing framework is **the best**. There exist many fine frameworks for writing C++ tests, and we have tremendous respect for the developers and users of them. We don't think there is (or will be) a single best framework - you have to pick the right tool for the particular task you are tackling. We created Google Test because we couldn't find the right combination of features and conveniences in an existing framework to satisfy _our_ needs. The following is a list of things that _we_ like about Google Test. We don't claim them to be unique to Google Test - rather, the combination of them makes Google Test the choice for us. We hope this list can help you decide whether it is for you too. * Google Test is designed to be portable: it doesn't require exceptions or RTTI; it works around various bugs in various compilers and environments; etc. As a result, it works on Linux, Mac OS X, Windows and several embedded operating systems. * Nonfatal assertions (`EXPECT_*`) have proven to be great time savers, as they allow a test to report multiple failures in a single edit-compile-test cycle. * It's easy to write assertions that generate informative messages: you just use the stream syntax to append any additional information, e.g. `ASSERT_EQ(5, Foo(i)) << " where i = " << i;`. It doesn't require a new set of macros or special functions. * Google Test automatically detects your tests and doesn't require you to enumerate them in order to run them. * Death tests are pretty handy for ensuring that your asserts in production code are triggered by the right conditions. * `SCOPED_TRACE` helps you understand the context of an assertion failure when it comes from inside a sub-routine or loop. * You can decide which tests to run using name patterns. This saves time when you want to quickly reproduce a test failure. * Google Test can generate XML test result reports that can be parsed by popular continuous build system like Hudson. * Simple things are easy in Google Test, while hard things are possible: in addition to advanced features like [global test environments](V1_6_AdvancedGuide.md#Global_Set-Up_and_Tear-Down) and tests parameterized by [values](V1_6_AdvancedGuide.md#value-parameterized-tests) or [types](V1_6_AdvancedGuide.md#typed-tests), Google Test supports various ways for the user to extend the framework -- if Google Test doesn't do something out of the box, chances are that a user can implement the feature using Google Test's public API, without changing Google Test itself. In particular, you can: * expand your testing vocabulary by defining [custom predicates](V1_6_AdvancedGuide.md#predicate-assertions-for-better-error-messages), * teach Google Test how to [print your types](V1_6_AdvancedGuide.md#teaching-google-test-how-to-print-your-values), * define your own testing macros or utilities and verify them using Google Test's [Service Provider Interface](V1_6_AdvancedGuide.md#catching-failures), and * reflect on the test cases or change the test output format by intercepting the [test events](V1_6_AdvancedGuide.md#extending-google-test-by-handling-test-events). ## I'm getting warnings when compiling Google Test. Would you fix them? ## We strive to minimize compiler warnings Google Test generates. Before releasing a new version, we test to make sure that it doesn't generate warnings when compiled using its CMake script on Windows, Linux, and Mac OS. Unfortunately, this doesn't mean you are guaranteed to see no warnings when compiling Google Test in your environment: * You may be using a different compiler as we use, or a different version of the same compiler. We cannot possibly test for all compilers. * You may be compiling on a different platform as we do. * Your project may be using different compiler flags as we do. It is not always possible to make Google Test warning-free for everyone. Or, it may not be desirable if the warning is rarely enabled and fixing the violations makes the code more complex. If you see warnings when compiling Google Test, we suggest that you use the `-isystem` flag (assuming your are using GCC) to mark Google Test headers as system headers. That'll suppress warnings from Google Test headers. ## Why should not test case names and test names contain underscore? ## Underscore (`_`) is special, as C++ reserves the following to be used by the compiler and the standard library: 1. any identifier that starts with an `_` followed by an upper-case letter, and 1. any identifier that containers two consecutive underscores (i.e. `__`) _anywhere_ in its name. User code is _prohibited_ from using such identifiers. Now let's look at what this means for `TEST` and `TEST_F`. Currently `TEST(TestCaseName, TestName)` generates a class named `TestCaseName_TestName_Test`. What happens if `TestCaseName` or `TestName` contains `_`? 1. If `TestCaseName` starts with an `_` followed by an upper-case letter (say, `_Foo`), we end up with `_Foo_TestName_Test`, which is reserved and thus invalid. 1. If `TestCaseName` ends with an `_` (say, `Foo_`), we get `Foo__TestName_Test`, which is invalid. 1. If `TestName` starts with an `_` (say, `_Bar`), we get `TestCaseName__Bar_Test`, which is invalid. 1. If `TestName` ends with an `_` (say, `Bar_`), we get `TestCaseName_Bar__Test`, which is invalid. So clearly `TestCaseName` and `TestName` cannot start or end with `_` (Actually, `TestCaseName` can start with `_` -- as long as the `_` isn't followed by an upper-case letter. But that's getting complicated. So for simplicity we just say that it cannot start with `_`.). It may seem fine for `TestCaseName` and `TestName` to contain `_` in the middle. However, consider this: ``` TEST(Time, Flies_Like_An_Arrow) { ... } TEST(Time_Flies, Like_An_Arrow) { ... } ``` Now, the two `TEST`s will both generate the same class (`Time_Files_Like_An_Arrow_Test`). That's not good. So for simplicity, we just ask the users to avoid `_` in `TestCaseName` and `TestName`. The rule is more constraining than necessary, but it's simple and easy to remember. It also gives Google Test some wiggle room in case its implementation needs to change in the future. If you violate the rule, there may not be immediately consequences, but your test may (just may) break with a new compiler (or a new version of the compiler you are using) or with a new version of Google Test. Therefore it's best to follow the rule. ## Why is it not recommended to install a pre-compiled copy of Google Test (for example, into /usr/local)? ## In the early days, we said that you could install compiled Google Test libraries on `*`nix systems using `make install`. Then every user of your machine can write tests without recompiling Google Test. This seemed like a good idea, but it has a got-cha: every user needs to compile his tests using the _same_ compiler flags used to compile the installed Google Test libraries; otherwise he may run into undefined behaviors (i.e. the tests can behave strangely and may even crash for no obvious reasons). Why? Because C++ has this thing called the One-Definition Rule: if two C++ source files contain different definitions of the same class/function/variable, and you link them together, you violate the rule. The linker may or may not catch the error (in many cases it's not required by the C++ standard to catch the violation). If it doesn't, you get strange run-time behaviors that are unexpected and hard to debug. If you compile Google Test and your test code using different compiler flags, they may see different definitions of the same class/function/variable (e.g. due to the use of `#if` in Google Test). Therefore, for your sanity, we recommend to avoid installing pre-compiled Google Test libraries. Instead, each project should compile Google Test itself such that it can be sure that the same flags are used for both Google Test and the tests. ## How do I generate 64-bit binaries on Windows (using Visual Studio 2008)? ## (Answered by Trevor Robinson) Load the supplied Visual Studio solution file, either `msvc\gtest-md.sln` or `msvc\gtest.sln`. Go through the migration wizard to migrate the solution and project files to Visual Studio 2008. Select `Configuration Manager...` from the `Build` menu. Select `<New...>` from the `Active solution platform` dropdown. Select `x64` from the new platform dropdown, leave `Copy settings from` set to `Win32` and `Create new project platforms` checked, then click `OK`. You now have `Win32` and `x64` platform configurations, selectable from the `Standard` toolbar, which allow you to toggle between building 32-bit or 64-bit binaries (or both at once using Batch Build). In order to prevent build output files from overwriting one another, you'll need to change the `Intermediate Directory` settings for the newly created platform configuration across all the projects. To do this, multi-select (e.g. using shift-click) all projects (but not the solution) in the `Solution Explorer`. Right-click one of them and select `Properties`. In the left pane, select `Configuration Properties`, and from the `Configuration` dropdown, select `All Configurations`. Make sure the selected platform is `x64`. For the `Intermediate Directory` setting, change the value from `$(PlatformName)\$(ConfigurationName)` to `$(OutDir)\$(ProjectName)`. Click `OK` and then build the solution. When the build is complete, the 64-bit binaries will be in the `msvc\x64\Debug` directory. ## Can I use Google Test on MinGW? ## We haven't tested this ourselves, but Per Abrahamsen reported that he was able to compile and install Google Test successfully when using MinGW from Cygwin. You'll need to configure it with: `PATH/TO/configure CC="gcc -mno-cygwin" CXX="g++ -mno-cygwin"` You should be able to replace the `-mno-cygwin` option with direct links to the real MinGW binaries, but we haven't tried that. Caveats: * There are many warnings when compiling. * `make check` will produce some errors as not all tests for Google Test itself are compatible with MinGW. We also have reports on successful cross compilation of Google Test MinGW binaries on Linux using [these instructions](http://wiki.wxwidgets.org/Cross-Compiling_Under_Linux#Cross-compiling_under_Linux_for_MS_Windows) on the WxWidgets site. Please contact `googletestframework@googlegroups.com` if you are interested in improving the support for MinGW. ## Why does Google Test support EXPECT\_EQ(NULL, ptr) and ASSERT\_EQ(NULL, ptr) but not EXPECT\_NE(NULL, ptr) and ASSERT\_NE(NULL, ptr)? ## Due to some peculiarity of C++, it requires some non-trivial template meta programming tricks to support using `NULL` as an argument of the `EXPECT_XX()` and `ASSERT_XX()` macros. Therefore we only do it where it's most needed (otherwise we make the implementation of Google Test harder to maintain and more error-prone than necessary). The `EXPECT_EQ()` macro takes the _expected_ value as its first argument and the _actual_ value as the second. It's reasonable that someone wants to write `EXPECT_EQ(NULL, some_expression)`, and this indeed was requested several times. Therefore we implemented it. The need for `EXPECT_NE(NULL, ptr)` isn't nearly as strong. When the assertion fails, you already know that `ptr` must be `NULL`, so it doesn't add any information to print ptr in this case. That means `EXPECT_TRUE(ptr ! NULL)` works just as well. If we were to support `EXPECT_NE(NULL, ptr)`, for consistency we'll have to support `EXPECT_NE(ptr, NULL)` as well, as unlike `EXPECT_EQ`, we don't have a convention on the order of the two arguments for `EXPECT_NE`. This means using the template meta programming tricks twice in the implementation, making it even harder to understand and maintain. We believe the benefit doesn't justify the cost. Finally, with the growth of Google Mock's [matcher](../../CookBook.md#using-matchers-in-google-test-assertions) library, we are encouraging people to use the unified `EXPECT_THAT(value, matcher)` syntax more often in tests. One significant advantage of the matcher approach is that matchers can be easily combined to form new matchers, while the `EXPECT_NE`, etc, macros cannot be easily combined. Therefore we want to invest more in the matchers than in the `EXPECT_XX()` macros. ## Does Google Test support running tests in parallel? ## Test runners tend to be tightly coupled with the build/test environment, and Google Test doesn't try to solve the problem of running tests in parallel. Instead, we tried to make Google Test work nicely with test runners. For example, Google Test's XML report contains the time spent on each test, and its `gtest_list_tests` and `gtest_filter` flags can be used for splitting the execution of test methods into multiple processes. These functionalities can help the test runner run the tests in parallel. ## Why don't Google Test run the tests in different threads to speed things up? ## It's difficult to write thread-safe code. Most tests are not written with thread-safety in mind, and thus may not work correctly in a multi-threaded setting. If you think about it, it's already hard to make your code work when you know what other threads are doing. It's much harder, and sometimes even impossible, to make your code work when you don't know what other threads are doing (remember that test methods can be added, deleted, or modified after your test was written). If you want to run the tests in parallel, you'd better run them in different processes. ## Why aren't Google Test assertions implemented using exceptions? ## Our original motivation was to be able to use Google Test in projects that disable exceptions. Later we realized some additional benefits of this approach: 1. Throwing in a destructor is undefined behavior in C++. Not using exceptions means Google Test's assertions are safe to use in destructors. 1. The `EXPECT_*` family of macros will continue even after a failure, allowing multiple failures in a `TEST` to be reported in a single run. This is a popular feature, as in C++ the edit-compile-test cycle is usually quite long and being able to fixing more than one thing at a time is a blessing. 1. If assertions are implemented using exceptions, a test may falsely ignore a failure if it's caught by user code: ``` try { ... ASSERT_TRUE(...) ... } catch (...) { ... } ``` The above code will pass even if the `ASSERT_TRUE` throws. While it's unlikely for someone to write this in a test, it's possible to run into this pattern when you write assertions in callbacks that are called by the code under test. The downside of not using exceptions is that `ASSERT_*` (implemented using `return`) will only abort the current function, not the current `TEST`. ## Why do we use two different macros for tests with and without fixtures? ## Unfortunately, C++'s macro system doesn't allow us to use the same macro for both cases. One possibility is to provide only one macro for tests with fixtures, and require the user to define an empty fixture sometimes: ``` class FooTest : public ::testing::Test {}; TEST_F(FooTest, DoesThis) { ... } ``` or ``` typedef ::testing::Test FooTest; TEST_F(FooTest, DoesThat) { ... } ``` Yet, many people think this is one line too many. :-) Our goal was to make it really easy to write tests, so we tried to make simple tests trivial to create. That means using a separate macro for such tests. We think neither approach is ideal, yet either of them is reasonable. In the end, it probably doesn't matter much either way. ## Why don't we use structs as test fixtures? ## We like to use structs only when representing passive data. This distinction between structs and classes is good for documenting the intent of the code's author. Since test fixtures have logic like `SetUp()` and `TearDown()`, they are better defined as classes. ## Why are death tests implemented as assertions instead of using a test runner? ## Our goal was to make death tests as convenient for a user as C++ possibly allows. In particular: * The runner-style requires to split the information into two pieces: the definition of the death test itself, and the specification for the runner on how to run the death test and what to expect. The death test would be written in C++, while the runner spec may or may not be. A user needs to carefully keep the two in sync. `ASSERT_DEATH(statement, expected_message)` specifies all necessary information in one place, in one language, without boilerplate code. It is very declarative. * `ASSERT_DEATH` has a similar syntax and error-reporting semantics as other Google Test assertions, and thus is easy to learn. * `ASSERT_DEATH` can be mixed with other assertions and other logic at your will. You are not limited to one death test per test method. For example, you can write something like: ``` if (FooCondition()) { ASSERT_DEATH(Bar(), "blah"); } else { ASSERT_EQ(5, Bar()); } ``` If you prefer one death test per test method, you can write your tests in that style too, but we don't want to impose that on the users. The fewer artificial limitations the better. * `ASSERT_DEATH` can reference local variables in the current function, and you can decide how many death tests you want based on run-time information. For example, ``` const int count = GetCount(); // Only known at run time. for (int i = 1; i <= count; i++) { ASSERT_DEATH({ double* buffer = new double[i]; ... initializes buffer ... Foo(buffer, i) }, "blah blah"); } ``` The runner-based approach tends to be more static and less flexible, or requires more user effort to get this kind of flexibility. Another interesting thing about `ASSERT_DEATH` is that it calls `fork()` to create a child process to run the death test. This is lightening fast, as `fork()` uses copy-on-write pages and incurs almost zero overhead, and the child process starts from the user-supplied statement directly, skipping all global and local initialization and any code leading to the given statement. If you launch the child process from scratch, it can take seconds just to load everything and start running if the test links to many libraries dynamically. ## My death test modifies some state, but the change seems lost after the death test finishes. Why? ## Death tests (`EXPECT_DEATH`, etc) are executed in a sub-process s.t. the expected crash won't kill the test program (i.e. the parent process). As a result, any in-memory side effects they incur are observable in their respective sub-processes, but not in the parent process. You can think of them as running in a parallel universe, more or less. ## The compiler complains about "undefined references" to some static const member variables, but I did define them in the class body. What's wrong? ## If your class has a static data member: ``` // foo.h class Foo { ... static const int kBar = 100; }; ``` You also need to define it _outside_ of the class body in `foo.cc`: ``` const int Foo::kBar; // No initializer here. ``` Otherwise your code is **invalid C++**, and may break in unexpected ways. In particular, using it in Google Test comparison assertions (`EXPECT_EQ`, etc) will generate an "undefined reference" linker error. ## I have an interface that has several implementations. Can I write a set of tests once and repeat them over all the implementations? ## Google Test doesn't yet have good support for this kind of tests, or data-driven tests in general. We hope to be able to make improvements in this area soon. ## Can I derive a test fixture from another? ## Yes. Each test fixture has a corresponding and same named test case. This means only one test case can use a particular fixture. Sometimes, however, multiple test cases may want to use the same or slightly different fixtures. For example, you may want to make sure that all of a GUI library's test cases don't leak important system resources like fonts and brushes. In Google Test, you share a fixture among test cases by putting the shared logic in a base test fixture, then deriving from that base a separate fixture for each test case that wants to use this common logic. You then use `TEST_F()` to write tests using each derived fixture. Typically, your code looks like this: ``` // Defines a base test fixture. class BaseTest : public ::testing::Test { protected: ... }; // Derives a fixture FooTest from BaseTest. class FooTest : public BaseTest { protected: virtual void SetUp() { BaseTest::SetUp(); // Sets up the base fixture first. ... additional set-up work ... } virtual void TearDown() { ... clean-up work for FooTest ... BaseTest::TearDown(); // Remember to tear down the base fixture // after cleaning up FooTest! } ... functions and variables for FooTest ... }; // Tests that use the fixture FooTest. TEST_F(FooTest, Bar) { ... } TEST_F(FooTest, Baz) { ... } ... additional fixtures derived from BaseTest ... ``` If necessary, you can continue to derive test fixtures from a derived fixture. Google Test has no limit on how deep the hierarchy can be. For a complete example using derived test fixtures, see [sample5](../samples/sample5_unittest.cc). ## My compiler complains "void value not ignored as it ought to be." What does this mean? ## You're probably using an `ASSERT_*()` in a function that doesn't return `void`. `ASSERT_*()` can only be used in `void` functions. ## My death test hangs (or seg-faults). How do I fix it? ## In Google Test, death tests are run in a child process and the way they work is delicate. To write death tests you really need to understand how they work. Please make sure you have read this. In particular, death tests don't like having multiple threads in the parent