openwrt/em-br6478acv2/lede/master-31e0f0ae - Edimax BR-6578AC V2 base from https://github.com/ulli-kroll/lede.git

diff options

author	Nicolas Thill <nico@openwrt.org>	2011-10-21 11:31:25 +0000
committer	Nicolas Thill <nico@openwrt.org>	2011-10-21 11:31:25 +0000
commit	0eab6e2a7d89fab112142027f207bcc5546fece4 (patch)
tree	9adf7bbbf1edc65df8036ae493ed99a141c42dce /include/host.mk
parent	55aeabae10d9429de0453d6df4271426478b406b (diff)
download	master-31e0f0ae-0eab6e2a7d89fab112142027f207bcc5546fece4.tar.gz master-31e0f0ae-0eab6e2a7d89fab112142027f207bcc5546fece4.tar.bz2 master-31e0f0ae-0eab6e2a7d89fab112142027f207bcc5546fece4.zip

upx: fix build error

g++ -O2 -Wall -W -Wcast-align -Wcast-qual -Wpointer-arith -Wshadow -Wwrite-strings -Werror -o compress.o -c compress.cpp cc1plus: warnings being treated as errors compress.cpp:75: error: unused parameter 'src' ... SVN-Revision: 28500

Diffstat (limited to 'include/host.mk')

0 files changed, 0 insertions, 0 deletions

# Introduction: Why Google C++ Testing Framework? # _Google C++ Testing Framework_ helps you write better C++ tests. No matter whether you work on Linux, Windows, or a Mac, if you write C++ code, Google Test can help you. So what makes a good test, and how does Google C++ Testing Framework fit in? We believe: 1. Tests should be _independent_ and _repeatable_. It's a pain to debug a test that succeeds or fails as a result of other tests. Google C++ Testing Framework isolates the tests by running each of them on a different object. When a test fails, Google C++ Testing Framework allows you to run it in isolation for quick debugging. 1. Tests should be well _organized_ and reflect the structure of the tested code. Google C++ Testing Framework groups related tests into test cases that can share data and subroutines. This common pattern is easy to recognize and makes tests easy to maintain. Such consistency is especially helpful when people switch projects and start to work on a new code base. 1. Tests should be _portable_ and _reusable_. The open-source community has a lot of code that is platform-neutral, its tests should also be platform-neutral. Google C++ Testing Framework works on different OSes, with different compilers (gcc, MSVC, and others), with or without exceptions, so Google C++ Testing Framework tests can easily work with a variety of configurations. (Note that the current release only contains build scripts for Linux - we are actively working on scripts for other platforms.) 1. When tests fail, they should provide as much _information_ about the problem as possible. Google C++ Testing Framework doesn't stop at the first test failure. Instead, it only stops the current test and continues with the next. You can also set up tests that report non-fatal failures after which the current test continues. Thus, you can detect and fix multiple bugs in a single run-edit-compile cycle. 1. The testing framework should liberate test writers from housekeeping chores and let them focus on the test _content_. Google C++ Testing Framework automatically keeps track of all tests defined, and doesn't require the user to enumerate them in order to run them. 1. Tests should be _fast_. With Google C++ Testing Framework, you can reuse shared resources across tests and pay for the set-up/tear-down only once, without making tests depend on each other. Since Google C++ Testing Framework is based on the popular xUnit architecture, you'll feel right at home if you've used JUnit or PyUnit before. If not, it will take you about 10 minutes to learn the basics and get started. So let's go! _Note:_ We sometimes refer to Google C++ Testing Framework informally as _Google Test_. # Setting up a New Test Project # To write a test program using Google Test, you need to compile Google Test into a library and link your test with it. We provide build files for some popular build systems (`msvc/` for Visual Studio, `xcode/` for Mac Xcode, `make/` for GNU make, `codegear/` for Borland C++ Builder, and the autotools script in the Google Test root directory). If your build system is not on this list, you can take a look at `make/Makefile` to learn how Google Test should be compiled (basically you want to compile `src/gtest-all.cc` with `GTEST_ROOT` and `GTEST_ROOT/include` in the header search path, where `GTEST_ROOT` is the Google Test root directory). Once you are able to compile the Google Test library, you should create a project or build target for your test program. Make sure you have `GTEST_ROOT/include` in the header search path so that the compiler can find `<gtest/gtest.h>` when compiling your test. Set up your test project to link with the Google Test library (for example, in Visual Studio, this is done by adding a dependency on `gtest.vcproj`). If you still have questions, take a look at how Google Test's own tests are built and use them as examples. # Basic Concepts # When using Google Test, you start by writing _assertions_, which are statements that check whether a condition is true. An assertion's result can be _success_, _nonfatal failure_, or _fatal failure_. If a fatal failure occurs, it aborts the current function; otherwise the program continues normally. _Tests_ use assertions to verify the tested code's behavior. If a test crashes or has a failed assertion, then it _fails_; otherwise it _succeeds_. A _test case_ contains one or many tests. You should group your tests into test cases that reflect the structure of the tested code. When multiple tests in a test case need to share common objects and subroutines, you can put them into a _test fixture_ class. A _test program_ can contain multiple test cases. We'll now explain how to write a test program, starting at the individual assertion level and building up to tests and test cases. # Assertions # Google Test assertions are macros that resemble function calls. You test a class or function by making assertions about its behavior. When an assertion fails, Google Test prints the assertion's source file and line number location, along with a failure message. You may also supply a custom failure message which will be appended to Google Test's message. The assertions come in pairs that test the same thing but have different effects on the current function. `ASSERT_*` versions generate fatal failures when they fail, and **abort the current function**. `EXPECT_*` versions generate nonfatal failures, which don't abort the current function. Usually `EXPECT_*` are preferred, as they allow more than one failures to be reported in a test. However, you should use `ASSERT_*` if it doesn't make sense to continue when the assertion in question fails. Since a failed `ASSERT_*` returns from the current function immediately, possibly skipping clean-up code that comes after it, it may cause a space leak. Depending on the nature of the leak, it may or may not be worth fixing - so keep this in mind if you get a heap checker error in addition to assertion errors. To provide a custom failure message, simply stream it into the macro using the `<<` operator, or a sequence of such operators. An example: ``` ASSERT_EQ(x.size(), y.size()) << "Vectors x and y are of unequal length"; for (int i = 0; i < x.size(); ++i) { EXPECT_EQ(x[i], y[i]) << "Vectors x and y differ at index " << i; } ``` Anything that can be streamed to an `ostream` can be streamed to an assertion macro--in particular, C strings and `string` objects. If a wide string (`wchar_t*`, `TCHAR*` in `UNICODE` mode on Windows, or `std::wstring`) is streamed to an assertion, it will be translated to UTF-8 when printed. ## Basic Assertions ## These assertions do basic true/false condition testing. | **Fatal assertion** | **Nonfatal assertion** | **Verifies** | |:--------------------|:-----------------------|:-------------| | `ASSERT_TRUE(`_condition_`)`; | `EXPECT_TRUE(`_condition_`)`; | _condition_ is true | | `ASSERT_FALSE(`_condition_`)`; | `EXPECT_FALSE(`_condition_`)`; | _condition_ is false | Remember, when they fail, `ASSERT_*` yields a fatal failure and returns from the current function, while `EXPECT_*` yields a nonfatal failure, allowing the function to continue running. In either case, an assertion failure means its containing test fails. _Availability_: Linux, Windows, Mac. ## Binary Comparison ## This section describes assertions that compare two values. | **Fatal assertion** | **Nonfatal assertion** | **Verifies** | |:--------------------|:-----------------------|:-------------| |`ASSERT_EQ(`_expected_`, `_actual_`);`|`EXPECT_EQ(`_expected_`, `_actual_`);`| _expected_ `==` _actual_ | |`ASSERT_NE(`_val1_`, `_val2_`);` |`EXPECT_NE(`_val1_`, `_val2_`);` | _val1_ `!=` _val2_ | |`ASSERT_LT(`_val1_`, `_val2_`);` |`EXPECT_LT(`_val1_`, `_val2_`);` | _val1_ `<` _val2_ | |`ASSERT_LE(`_val1_`, `_val2_`);` |`EXPECT_LE(`_val1_`, `_val2_`);` | _val1_ `<=` _val2_ | |`ASSERT_GT(`_val1_`, `_val2_`);` |`EXPECT_GT(`_val1_`, `_val2_`);` | _val1_ `>` _val2_ | |`ASSERT_GE(`_val1_`, `_val2_`);` |`EXPECT_GE(`_val1_`, `_val2_`);` | _val1_ `>=` _val2_ | In the event of a failure, Google Test prints both _val1_ and _val2_ . In `ASSERT_EQ*` and `EXPECT_EQ*` (and all other equality assertions we'll introduce later), you should put the expression you want to test in the position of _actual_, and put its expected value in _expected_, as Google Test's failure messages are optimized for this convention. Value arguments must be comparable by the assertion's comparison operator or you'll get a compiler error. Values must also support the `<<` operator for streaming to an `ostream`. All built-in types support this. These assertions can work with a user-defined type, but only if you define the corresponding comparison operator (e.g. `==`, `<`, etc). If the corresponding operator is defined, prefer using the `ASSERT_*()` macros because they will print out not only the result of the comparison, but the two operands as well. Arguments are always evaluated exactly once. Therefore, it's OK for the arguments to have side effects. However, as with any ordinary C/C++ function, the arguments' evaluation order is undefined (i.e. the compiler is free to choose any order) and your code should not depend on any particular argument evaluation order. `ASSERT_EQ()` does pointer equality on pointers. If used on two C strings, it tests if they are in the same memory location, not if they have the same value. Therefore, if you want to compare C strings (e.g. `const char*`) by value, use `ASSERT_STREQ()` , which will be described later on. In particular, to assert that a C string is `NULL`, use `ASSERT_STREQ(NULL, c_string)` . However, to compare two `string` objects, you should use `ASSERT_EQ`. Macros in this section work with both narrow and wide string objects (`string` and `wstring`). _Availability_: Linux, Windows, Mac. ## String Comparison ## The assertions in this group compare two **C strings**. If you want to compare two `string` objects, use `EXPECT_EQ`, `EXPECT_NE`, and etc instead. | **Fatal assertion** | **Nonfatal assertion** | **Verifies** | |:--------------------|:-----------------------|:-------------| | `ASSERT_STREQ(`_expected\_str_`, `_actual\_str_`);` | `EXPECT_STREQ(`_expected\_str_`, `_actual\_str_`);` | the two C strings have the same content | | `ASSERT_STRNE(`_str1_`, `_str2_`);` | `EXPECT_STRNE(`_str1_`, `_str2_`);` | the two C strings have different content | | `ASSERT_STRCASEEQ(`_expected\_str_`, `_actual\_str_`);`| `EXPECT_STRCASEEQ(`_expected\_str_`, `_actual\_str_`);` | the two C strings have the same content, ignoring case | | `ASSERT_STRCASENE(`_str1_`, `_str2_`);`| `EXPECT_STRCASENE(`_str1_`, `_str2_`);` | the two C strings have different content, ignoring case | Note that "CASE" in an assertion name means that case is ignored. `*STREQ*` and `*STRNE*` also accept wide C strings (`wchar_t*`). If a comparison of two wide strings fails, their values will be printed as UTF-8 narrow strings. A `NULL` pointer and an empty string are considered _different_. _Availability_: Linux, Windows, Mac. See also: For more string comparison tricks (substring, prefix, suffix, and regular expression matching, for example), see the [AdvancedGuide Advanced Google Test Guide]. # Simple Tests # To create a test: 1. Use the `TEST()` macro to define and name a test function, These are ordinary C++ functions that don't return a value. 1. In this function, along with any valid C++ statements you want to include, use the various Google Test assertions to check values. 1. The test's result is determined by the assertions; if any assertion in the test fails (either fatally or non-fatally), or if the test crashes, the entire test fails. Otherwise, it succeeds. ``` TEST(test_case_name, test_name) { ... test body ... } ``` `TEST()` arguments go from general to specific. The _first_ argument is the name of the test case, and the _second_ argument is the test's name within the test case. Remember that a test case can contain any number of individual tests. A test's _full name_ consists of its containing test case and its individual name. Tests from different test cases can have the same individual name. For example, let's take a simple integer function: ``` int Factorial(int n); // Returns the factorial of n ``` A test case for this function might look like: ``` // Tests factorial of 0. TEST(FactorialTest, HandlesZeroInput) { EXPECT_EQ(1, Factorial(0)); } // Tests factorial of positive numbers. TEST(FactorialTest, HandlesPositiveInput) { EXPECT_EQ(1, Factorial(1)); EXPECT_EQ(2, Factorial(2)); EXPECT_EQ(6, Factorial(3)); EXPECT_EQ(40320, Factorial(8)); } ``` Google Test groups the test results by test cases, so logically-related tests should be in the same test case; in other words, the first argument to their `TEST()` should be the same. In the above example, we have two tests, `HandlesZeroInput` and `HandlesPositiveInput`, that belong to the same test case `FactorialTest`. _Availability_: Linux, Windows, Mac. # Test Fixtures: Using the Same Data Configuration for Multiple Tests # If you find yourself writing two or more tests that operate on similar data, you can use a _test fixture_. It allows you to reuse the same configuration of objects for several different tests. To create a fixture, just: 1. Derive a class from `::testing::Test` . Start its body with `protected:` or `public:` as we'll want to access fixture members from sub-classes. 1. Inside the class, declare any objects you plan to use. 1. If necessary, write a default constructor or `SetUp()` function to prepare the objects for each test. A common mistake is to spell `SetUp()` as `Setup()` with a small `u` - don't let that happen to you. 1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](V1_5_FAQ.md#should-i-use-the-constructordestructor-of-the-test-fixture-or-the-set-uptear-down-function).


context:
space:
mode: