buildroot/package/directfb-examples, branch 2016.08

directfb-examples: indentation cleanup

2015-12-20T12:54:31+00:00

Signed-off-by: Jerzy Grzegorek Signed-off-by: Thomas Petazzoni

directfb-examples: bump to 1.7.0

2015-09-10T12:06:51+00:00

This commit bumps the directfb-examples package to use the upstream 1.7.0 version. Signed-off-by: Thomas Petazzoni Signed-off-by: Peter Korsgaard

directfb-examples: do not install to staging

2015-09-10T12:06:38+00:00

DirectFB examples are just examples, there is no reason to install them to the staging directory. Signed-off-by: Thomas Petazzoni Signed-off-by: Peter Korsgaard

directfb-examples: remove options for each example

2015-09-10T12:03:46+00:00

For some historical reasons, the directfb-examples package has one sub-option for each example, and the .mk files go through some great lengths to install only the needed data files for each example. This is a bit silly for several reasons: * In no other Buildroot package we do offer such a fine-grained selection of what the package installs; * directfb-examples are examples, they are therefore typically not meant to be used on a final production system, but more during development or for demonstration. Those are situations where size generally isn't that critical (all installed, the package takes 2.4 MB on the rootfs); * Those options and the .mk file logic has to be updated whenever the package is bumped; * Users can always use a post-build script to keep only the examples they are interested in. All the options are moved to Config.in.legacy. However, we could debate on whether this is actually useful, since the main option BR2_PACKAGE_DIRECTFB_EXAMPLES will now install a superset of whatever was selected before through sub-options. Signed-off-by: Thomas Petazzoni Signed-off-by: Peter Korsgaard

directfb-examples: add hash file

2015-07-28T20:37:14+00:00

Signed-off-by: Gustavo Zacarias Signed-off-by: Thomas Petazzoni

directfb-examples: drop usr/bin path from sub options text

2015-02-26T23:15:59+00:00

Nowhere else do we list the explicit path where binaries are installed to, so drop it from here. Signed-off-by: Peter Korsgaard

directfb-examples: drop explicit stripping when installing into target

2015-02-26T23:13:44+00:00

Stripping is globally handled by target-finalize (if enabled), so drop it from here. Reported-by: Peter Seiderer Signed-off-by: Peter Korsgaard

directfb-examples: explicitly add -lstdc++ for static build

2015-02-26T23:11:32+00:00

Fixes [1] and [2]: undefined reference to `___cxa_pure_virtual' undefined reference to `___gxx_personality_v0' [1] http://autobuild.buildroot.net/results/bd0/bd0f4b3e41bf6330f83e3d9b58d985cc63506a3b/ [2] http://autobuild.buildroot.net/results/584/584ace383204d97fcaad37742e2e035ca78a3d10/ Signed-off-by: Peter Seiderer Signed-off-by: Peter Korsgaard

package/*: rename patches according to the new policy

2015-02-03T13:52:56+00:00

Autogenerated from rename-patch.py (http://patchwork.ozlabs.org/patch/403345) Signed-off-by: Samuel Martin Signed-off-by: Peter Korsgaard

Config.in files: use if/endif instead of 'depends on' for main symbol

2013-12-25T11:21:39+00:00

In the Config.in file of package foo, it often happens that there are other symbols besides BR2_PACKAGE_FOO. Typically, these symbols only make sense when foo itself is enabled. There are two ways to express this: with depends on BR2_PACKAGE_FOO in each extra symbol, or with if BR2_PACKAGE_FOO ... endif around the entire set of extra symbols. The if/endif approach avoids the repetition of 'depends on' statements on multiple symbols, so this is clearly preferred. But even when there is only one extra symbol, if/endif is a more logical choice: - it is future-proof for when extra symbols are added - it allows to have just one strategy instead of two (less confusion) This patch modifies the Config.in files accordingly. Signed-off-by: Thomas De Schampheleire Signed-off-by: Thomas Petazzoni