* [Buildroot] [PATCH 0/0] Updating directfb and divine
@ 2013-03-10 9:47 Carsten Schoenert
2013-03-10 9:47 ` [Buildroot] [PATCH 1/4] directfb: bumping version to 1.6.3 Carsten Schoenert
` (3 more replies)
0 siblings, 4 replies; 19+ messages in thread
From: Carsten Schoenert @ 2013-03-10 9:47 UTC (permalink / raw)
To: buildroot
Hello,
as I wrote I want to experementing a little bit with ilixi from the
directfb people.
To do this the directfb files must be upgraded. I bumped the directfb
and divine version to 1.6.3.
Also I made some expanding to the helper strings inside the directfb
package an fixed up some little typos to the directfb variables.
Until now no error happen because the variable was misspelled in all
ivolved files. Correcting this just for clearness.
Thanks to Thomas for helping fighting some autotool related package
stuff inside the divine package.
Regards
Carsten
^ permalink raw reply [flat|nested] 19+ messages in thread* [Buildroot] [PATCH 1/4] directfb: bumping version to 1.6.3 2013-03-10 9:47 [Buildroot] [PATCH 0/0] Updating directfb and divine Carsten Schoenert @ 2013-03-10 9:47 ` Carsten Schoenert 2013-03-10 10:32 ` Thomas Petazzoni 2013-03-10 9:47 ` [Buildroot] [PATCH 2/4] divine: " Carsten Schoenert ` (2 subsequent siblings) 3 siblings, 1 reply; 19+ messages in thread From: Carsten Schoenert @ 2013-03-10 9:47 UTC (permalink / raw) To: buildroot From: Carsten Schoenert <c.schoenert@gmail.com> Signed-off-by: Carsten Schoenert <c.schoenert@gmail.com> --- package/directfb/directfb.mk | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/directfb/directfb.mk b/package/directfb/directfb.mk index 4f05ed2..8c701db 100644 --- a/package/directfb/directfb.mk +++ b/package/directfb/directfb.mk @@ -3,8 +3,8 @@ # directfb # ############################################################# -DIRECTFB_VERSION_MAJOR = 1.4 -DIRECTFB_VERSION = $(DIRECTFB_VERSION_MAJOR).17 +DIRECTFB_VERSION_MAJOR = 1.6 +DIRECTFB_VERSION = $(DIRECTFB_VERSION_MAJOR).3 DIRECTFB_SITE = http://www.directfb.org/downloads/Core/DirectFB-$(DIRECTFB_VERSION_MAJOR) DIRECTFB_SOURCE = DirectFB-$(DIRECTFB_VERSION).tar.gz DIRECTFB_LICENSE = LGPLv2.1+ -- 1.7.10.4 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 1/4] directfb: bumping version to 1.6.3 2013-03-10 9:47 ` [Buildroot] [PATCH 1/4] directfb: bumping version to 1.6.3 Carsten Schoenert @ 2013-03-10 10:32 ` Thomas Petazzoni 2013-03-10 12:34 ` Carsten Schoenert 2013-03-10 16:50 ` Carsten Schoenert 0 siblings, 2 replies; 19+ messages in thread From: Thomas Petazzoni @ 2013-03-10 10:32 UTC (permalink / raw) To: buildroot Dear Carsten Schoenert, On Sun, 10 Mar 2013 10:47:35 +0100, Carsten Schoenert wrote: > -DIRECTFB_VERSION_MAJOR = 1.4 > -DIRECTFB_VERSION = $(DIRECTFB_VERSION_MAJOR).17 > +DIRECTFB_VERSION_MAJOR = 1.6 > +DIRECTFB_VERSION = $(DIRECTFB_VERSION_MAJOR).3 > DIRECTFB_SITE = http://www.directfb.org/downloads/Core/DirectFB-$(DIRECTFB_VERSION_MAJOR) > DIRECTFB_SOURCE = DirectFB-$(DIRECTFB_VERSION).tar.gz > DIRECTFB_LICENSE = LGPLv2.1+ This looks good. However, we have a number of packages that depend or can use DirectFB: cairo, directfb-examples, libecore, libevas, libgtk2, links, lite, gst-plugins-bad, opencv, qt, sawman, sdl, webkit. Did you test if those still build after this DirectFB bump? I have no idea if the DirectFB bump from 1.4.x to 1.6.x is a major bump (like with API breakage) or a minor bump. Depending on that, some testing of the packages using DirectFB would be needed, or not. Note that we don't necessarily require all those packages to continue to build with DirectFB 1.6.x: if those packages haven't adapted to the new DirectFB versions, then it's an upstream problem. However, if some of those packages don't build, it would be good to update their Config.in to ensure that the DirectFB variant is no longer offered/used. Also, do just a reasonable amount of testing: our autobuilders will anyway do a global testing of many combinations. But it's good to at least check a few packages. If they work fine with the DirectFB bump, then it's a good indication that the DirectFB bump probably didn't introduce too much API breakage. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 1/4] directfb: bumping version to 1.6.3 2013-03-10 10:32 ` Thomas Petazzoni @ 2013-03-10 12:34 ` Carsten Schoenert 2013-03-17 13:59 ` Carsten Schoenert 2013-03-10 16:50 ` Carsten Schoenert 1 sibling, 1 reply; 19+ messages in thread From: Carsten Schoenert @ 2013-03-10 12:34 UTC (permalink / raw) To: buildroot Hello Thomas, Am 10.03.2013 11:32, schrieb Thomas Petazzoni: > This looks good. However, we have a number of packages that depend or > can use DirectFB: cairo, directfb-examples, libecore, libevas, libgtk2, > links, lite, gst-plugins-bad, opencv, qt, sawman, sdl, webkit. Did you > test if those still build after this DirectFB bump? I have no idea if > the DirectFB bump from 1.4.x to 1.6.x is a major bump (like with API > breakage) or a minor bump. Depending on that, some testing of the > packages using DirectFB would be needed, or not. Ah yes, good point! I'll pick up some of these packages an will do some tests. But I have to look once again to the config of directfb itself, I think there will have changed some configure options between this different versions of directfb. This point comes right now in mind. > Note that we don't necessarily require all those packages to continue > to build with DirectFB 1.6.x: if those packages haven't adapted to the > new DirectFB versions, then it's an upstream problem. However, if some > of those packages don't build, it would be good to update their > Config.in to ensure that the DirectFB variant is no longer offered/used. Indeed, there will hopefully be not to much packages affected. It depends a little bit on the test locally or done by the autobuilders. > Also, do just a reasonable amount of testing: our autobuilders will > anyway do a global testing of many combinations. But it's good to at > least check a few packages. If they work fine with the DirectFB bump, > then it's a good indication that the DirectFB bump probably didn't > introduce too much API breakage. That's good, I can here just check the build with my arm toolchain. ;) O.k. now I need some time to readjust the patchset, thanks for your suggestions! Regards Carsten ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 1/4] directfb: bumping version to 1.6.3 2013-03-10 12:34 ` Carsten Schoenert @ 2013-03-17 13:59 ` Carsten Schoenert 2013-03-21 6:56 ` Arnout Vandecappelle 0 siblings, 1 reply; 19+ messages in thread From: Carsten Schoenert @ 2013-03-17 13:59 UTC (permalink / raw) To: buildroot Hello Thomas, all, Am 10.03.2013 13:34, schrieb Carsten Schoenert: > Hello Thomas, > > Am 10.03.2013 11:32, schrieb Thomas Petazzoni: >> This looks good. However, we have a number of packages that depend or >> can use DirectFB: cairo, directfb-examples, libecore, libevas, libgtk2, >> links, lite, gst-plugins-bad, opencv, qt, sawman, sdl, webkit. Did you >> test if those still build after this DirectFB bump? I have no idea if >> the DirectFB bump from 1.4.x to 1.6.x is a major bump (like with API >> breakage) or a minor bump. Depending on that, some testing of the >> packages using DirectFB would be needed, or not. > > Ah yes, good point! I'll pick up some of these packages an will do some > tests. > But I have to look once again to the config of directfb itself, I think > there will have changed some configure options between this different > versions of directfb. This point comes right now in mind. I have diffed the output from 'configure --help' of the directfb package from the old version (1.4.17) to the new version (1.6.3). There are one option removed and a few new are appended. This option is now not living anymore. > --enable-sysfs build with sysfs support [default=auto] The following options ([auto])are new. > --enable-sysfs build with sysfs support [default=auto] > --enable-mesa build with Mesa support [default=auto] And thees options are [default=yes]. > --enable-dynload enable dynload support [default=yes] > --enable-multicore enable multicore support [default=yes] > --enable-mng build MNG image provider [default=yes] > --enable-imlib2 build Imlib2 image provider [default=yes] > --enable-pnm build PNM (PBM/PGM/PPM) image provider [default=yes] > --enable-svg build SVG image provider [default=yes] > --enable-mpeg2 build MPEG2 image provider [default=yes] > --enable-bmp build BMP image provider [default=yes] > --enable-jpeg2000 build JPEG2000 image provider [default=yes] And at last one option with [default=no]. > --enable-gstreamer build gstreamer video provider [default=no] I'm not already getting the logic inside the directfb.mk so how to handle thees different options in the future? I mean, what's the point to implement a configure option or not? I know some options are platform specific and for me it is particularly implemented. For example, there are configure options for jpeg, gif and png support but not for freetype (all this configure options are [default=yes]) and freetype is also explicitly set per default in the DIRECTFB_CONF_OPT with '--enable-freetype'. Why are the options for the gfxdrivers and inputlist are not complete filled in the Config.in and directfb.mk file? In the directfb.mk file is a check for BR2_PACKAGE_DIRECTFB_CYBER5K but the Config.in file has no option for this. Forgotten? I can try to rework this two files, but to save unneeded work any help is appreciated. Can someone point me to the right direction? Regards Carsten ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 1/4] directfb: bumping version to 1.6.3 2013-03-17 13:59 ` Carsten Schoenert @ 2013-03-21 6:56 ` Arnout Vandecappelle 2013-03-21 18:06 ` Carsten Schoenert 0 siblings, 1 reply; 19+ messages in thread From: Arnout Vandecappelle @ 2013-03-21 6:56 UTC (permalink / raw) To: buildroot On 17/03/13 14:59, Carsten Schoenert wrote: > Hello Thomas, all, > > Am 10.03.2013 13:34, schrieb Carsten Schoenert: [snip] > This option is now not living anymore. >> --enable-sysfs build with sysfs support [default=auto] > > The following options ([auto])are new. >> --enable-sysfs build with sysfs support [default=auto] Er, I guess you made a mistake here? sysfs support is still an option? >> --enable-mesa build with Mesa support [default=auto] > > And thees options are [default=yes]. >> --enable-dynload enable dynload support [default=yes] >> --enable-multicore enable multicore support [default=yes] >> --enable-mng build MNG image provider [default=yes] >> --enable-imlib2 build Imlib2 image provider [default=yes] >> --enable-pnm build PNM (PBM/PGM/PPM) image provider [default=yes] >> --enable-svg build SVG image provider [default=yes] >> --enable-mpeg2 build MPEG2 image provider [default=yes] >> --enable-bmp build BMP image provider [default=yes] >> --enable-jpeg2000 build JPEG2000 image provider [default=yes] > > And at last one option with [default=no]. >> --enable-gstreamer build gstreamer video provider [default=no] > > I'm not already getting the logic inside the directfb.mk so how to > handle thees different options in the future? I mean, what's the point > to implement a configure option or not? I know some options are platform > specific and for me it is particularly implemented. > > For example, there are configure options for jpeg, gif and png support > but not for freetype (all this configure options are [default=yes]) and > freetype is also explicitly set per default in the DIRECTFB_CONF_OPT > with '--enable-freetype'. > > Why are the options for the gfxdrivers and inputlist are not complete > filled in the Config.in and directfb.mk file? > In the directfb.mk file is a check for BR2_PACKAGE_DIRECTFB_CYBER5K but > the Config.in file has no option for this. Forgotten? > > I can try to rework this two files, but to save unneeded work any help > is appreciated. Can someone point me to the right direction? How it _should_ be is that as many configure options as possible are specified explicitly in the .mk file. In particular, any configure option that is set to the non-default value in the .mk file, should also be set explicitly to the default value. But of course, a lot of that is not the case now, because the rule is not strictly enforced. Anything you fix during the version bump is nice to have, but you're not obliged to fix it if you don't know how to (and we expect you to have tested the change, so that means trying out a number of different configurations...). Regarding the cyber5k thing: that's indeed an oversight from when the gfxdrivers options were added. Since nobody has complained about it, I guess you can just remove the option. Or you can add it to Config.in, whatever you like. Regards, Arnout -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 1/4] directfb: bumping version to 1.6.3 2013-03-21 6:56 ` Arnout Vandecappelle @ 2013-03-21 18:06 ` Carsten Schoenert 2013-03-21 19:13 ` Thomas Petazzoni 0 siblings, 1 reply; 19+ messages in thread From: Carsten Schoenert @ 2013-03-21 18:06 UTC (permalink / raw) To: buildroot Hello Arnout, hello Thomas, Am 21.03.2013 07:56, schrieb Arnout Vandecappelle: >> This option is now not living anymore. >>> --enable-sysfs build with sysfs support [default=auto] >> >> The following options ([auto])are new. >>> --enable-sysfs build with sysfs support [default=auto] > > Er, I guess you made a mistake here? sysfs support is still an option? Yes and no. :) Yes, I made a copy & paste error, and No, the '-sysfs' option isn't there in version 1.6.3. >> I can try to rework this two files, but to save unneeded work any help >> is appreciated. Can someone point me to the right direction? > > How it _should_ be is that as many configure options as possible are > specified explicitly in the .mk file. In particular, any configure option > that is set to the non-default value in the .mk file, should also be set > explicitly to the default value. You mean for example --enable-svg build SVG image provider [default=yes] should be set by default to 'yes' and so on for the other 'default=yes' options? The options with default=auto should will be automaticly detected by configure and mostly it isn't useful to explicitly deactivating them because that breaks the binarys so leaving them. > But of course, a lot of that is not the case now, because the rule is > not strictly enforced. Anything you fix during the version bump is nice > to have, but you're not obliged to fix it if you don't know how to (and > we expect you to have tested the change, so that means trying out a > number of different configurations...). Yes I can't test all variations so thats why I ask here how to do it best. I'm working with a toolchain for a ARMv6 platform on a settopbox there we need directfb so I test mostly of my work on this settopbox. > Regarding the cyber5k thing: that's indeed an oversight from when the > gfxdrivers options were added. Since nobody has complained about it, I > guess you can just remove the option. Or you can add it to Config.in, > whatever you like. O.k. now it is a bit clearly to me. Hopefully I find some time on the weekend to get into it. Thanks for your suggestions. Regards Carsten ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 1/4] directfb: bumping version to 1.6.3 2013-03-21 18:06 ` Carsten Schoenert @ 2013-03-21 19:13 ` Thomas Petazzoni 2013-04-02 21:56 ` Carsten Schoenert 0 siblings, 1 reply; 19+ messages in thread From: Thomas Petazzoni @ 2013-03-21 19:13 UTC (permalink / raw) To: buildroot Dear Carsten Schoenert, On Thu, 21 Mar 2013 19:06:13 +0100, Carsten Schoenert wrote: > > How it _should_ be is that as many configure options as possible are > > specified explicitly in the .mk file. In particular, any configure option > > that is set to the non-default value in the .mk file, should also be set > > explicitly to the default value. > > You mean for example > --enable-svg build SVG image provider [default=yes] > should be set by default to 'yes' and so on for the other 'default=yes' > options? > The options with default=auto should will be automaticly detected by > configure and mostly it isn't useful to explicitly deactivating them > because that breaks the binarys so leaving them. No, I think Arnout means that we should leave as few options "automatically" detected as possible. For example, we really like to have: ifeq ($(BR2_PACKAGE_FOO_FEATURE_BAR),y) FOO_CONF_OPT += --enable-bar else FOO_CONF_OPT += --disable-bar endif and for all options that are not explicitly --enable-<bleh> somewhere, have a global: FOO_CONF_OPT += \ --disable-<bleh> \ --disable-<blah> this avoids the configure script from automatically detecting things on the host machine that we don't want it to detect. > > But of course, a lot of that is not the case now, because the rule is > > not strictly enforced. Anything you fix during the version bump is nice > > to have, but you're not obliged to fix it if you don't know how to (and > > we expect you to have tested the change, so that means trying out a > > number of different configurations...). > > Yes I can't test all variations so thats why I ask here how to do it > best. I'm working with a toolchain for a ARMv6 platform on a settopbox > there we need directfb so I test mostly of my work on this settopbox. We have autobuilders that test a big number of random configurations, so you definitely don't have to test all combinations. Thanks, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 1/4] directfb: bumping version to 1.6.3 2013-03-21 19:13 ` Thomas Petazzoni @ 2013-04-02 21:56 ` Carsten Schoenert 0 siblings, 0 replies; 19+ messages in thread From: Carsten Schoenert @ 2013-04-02 21:56 UTC (permalink / raw) To: buildroot Hello Thomas, Hello Arnout, Am 21.03.2013 20:13, schrieb Thomas Petazzoni: > No, I think Arnout means that we should leave as few options > "automatically" detected as possible. > > For example, we really like to have: > > ifeq ($(BR2_PACKAGE_FOO_FEATURE_BAR),y) > FOO_CONF_OPT += --enable-bar > else > FOO_CONF_OPT += --disable-bar > endif > > and for all options that are not explicitly --enable-<bleh> somewhere, > have a global: > > FOO_CONF_OPT += \ > --disable-<bleh> \ > --disable-<blah> > > this avoids the configure script from automatically detecting things on > the host machine that we don't want it to detect. some little status info on that. The last days I worked on the "new" Config.in and the directfb.mk Makefile with your suggestions. Until now I would say the most options are implemented and I can also build the most of them. But I found some issues inside the directfb archive (missing headers :) and some code errors). I found one patch to fix the code errors and cook one other to fix a configure problem, but the missing headers are just to fix if the package would switch to a git checkout. I wrote up to upstream to fix the header and the code error. I will wait for response and in the between time I will more clean up my current work. Some of the new options have new dependencies like libsvg-cairo, linotyp, mng or jasper for jpeg2000. The libsvg-cairo package I will try to implement if I find some free time for it, the other dependencies have to find some other person. ;) Regards Carsten ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 1/4] directfb: bumping version to 1.6.3 2013-03-10 10:32 ` Thomas Petazzoni 2013-03-10 12:34 ` Carsten Schoenert @ 2013-03-10 16:50 ` Carsten Schoenert 2013-03-10 17:25 ` Thomas Petazzoni 1 sibling, 1 reply; 19+ messages in thread From: Carsten Schoenert @ 2013-03-10 16:50 UTC (permalink / raw) To: buildroot Hello Thomas, Am 10.03.2013 11:32, schrieb Thomas Petazzoni: > This looks good. However, we have a number of packages that depend or > can use DirectFB: cairo, directfb-examples, libecore, libevas, libgtk2, > links, lite, gst-plugins-bad, opencv, qt, sawman, sdl, webkit. Did you > test if those still build after this DirectFB bump? I have no idea if > the DirectFB bump from 1.4.x to 1.6.x is a major bump (like with API > breakage) or a minor bump. Depending on that, some testing of the > packages using DirectFB would be needed, or not. I have greped which packages depending direct on the directfb package, this aren't much, I was a little bit surprised and suspected more packages. > $ git grep -n "depends on BR2_PACKAGE_DIRECTFB" > package/directfb-examples/Config.in:3: depends on BR2_PACKAGE_DIRECTFB > ... # more hits on directfb-exables I tested the directfb-examples, this package has to be bumped. This I have successful tested and prepared three patches here. > package/divine/Config.in:3: depends on BR2_PACKAGE_DIRECTFB Already done in one of my previous patches. > package/efl/libecore/Config.in:15: depends on BR2_PACKAGE_DIRECTFB Successful builded. > package/efl/libevas/Config.in:56: depends on BR2_PACKAGE_DIRECTFB Successful builded with most of the options (expect OpenGL related stuff). > package/lite/Config.in:3: depends on BR2_PACKAGE_DIRECTFB Works perfect, the version is still the current version. > package/qt/Config.gfx.in:23: depends on BR2_PACKAGE_DIRECTFB This I will not test, to big the QT beast. :) > package/sawman/Config.in:3: depends on BR2_PACKAGE_DIRECTFB Sawan must also bumped to the current version, locally successful done and builded. Also prepared a patch. > package/sdl/Config.in:18: depends on BR2_PACKAGE_DIRECTFB SDL works successful with the new directfb version. In summary it looks good. So hopefully I will post later a new patch series. Regards Carsten ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 1/4] directfb: bumping version to 1.6.3 2013-03-10 16:50 ` Carsten Schoenert @ 2013-03-10 17:25 ` Thomas Petazzoni 0 siblings, 0 replies; 19+ messages in thread From: Thomas Petazzoni @ 2013-03-10 17:25 UTC (permalink / raw) To: buildroot Dear Carsten Schoenert, On Sun, 10 Mar 2013 17:50:37 +0100, Carsten Schoenert wrote: > In summary it looks good. > So hopefully I will post later a new patch series. Excellent, thanks a lot for all this testing effort! Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 2/4] divine: bumping version to 1.6.3 2013-03-10 9:47 [Buildroot] [PATCH 0/0] Updating directfb and divine Carsten Schoenert 2013-03-10 9:47 ` [Buildroot] [PATCH 1/4] directfb: bumping version to 1.6.3 Carsten Schoenert @ 2013-03-10 9:47 ` Carsten Schoenert 2013-03-10 9:47 ` [Buildroot] [PATCH 3/4] directfb: expanding the help strings Carsten Schoenert 2013-03-10 9:47 ` [Buildroot] [PATCH 4/4] directfb: fixing typo in variables Carsten Schoenert 3 siblings, 0 replies; 19+ messages in thread From: Carsten Schoenert @ 2013-03-10 9:47 UTC (permalink / raw) To: buildroot From: Carsten Schoenert <c.schoenert@gmail.com> To be identical to the version of directfb switching also to version 1.6.3. The divine package needs at minimum directfb 1.6.0 as dependencie. Adding the license information to the package divine. Also switch to Git for getting the package source because the tar.gz for version 1.6.3 on directfb.org is broken because of a missed header file inside. Signed-off-by: Carsten Schoenert <c.schoenert@gmail.com> --- package/divine/divine.mk | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/package/divine/divine.mk b/package/divine/divine.mk index b949601..df59a18 100644 --- a/package/divine/divine.mk +++ b/package/divine/divine.mk @@ -4,11 +4,16 @@ # ############################################################# -DIVINE_VERSION = 0.4.0 -DIVINE_SITE = http://www.directfb.org/downloads/Extras -DIVINE_SOURCE = DiVine-$(DIVINE_VERSION).tar.gz +# tagged version 1.6.3 +DIVINE_VERSION = 83cafc257a42b9465cd9d6185bf66b8c1b7ed704 +DIVINE_SITE = git://git.directfb.org/git/directfb/extras/DiVine.git +DIVINE_LICENSE = LGPLv2.1+ +DIVINE_LICENSE_FILE = COPYING DIVINE_INSTALL_STAGING = YES DIVINE_DEPENDENCIES = directfb DIVINE_CONFIG_SCRIPTS = divine-config +# package has no configure script so we have generate it +DIVINE_AUTORECONF = YES + $(eval $(autotools-package)) -- 1.7.10.4 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 3/4] directfb: expanding the help strings 2013-03-10 9:47 [Buildroot] [PATCH 0/0] Updating directfb and divine Carsten Schoenert 2013-03-10 9:47 ` [Buildroot] [PATCH 1/4] directfb: bumping version to 1.6.3 Carsten Schoenert 2013-03-10 9:47 ` [Buildroot] [PATCH 2/4] divine: " Carsten Schoenert @ 2013-03-10 9:47 ` Carsten Schoenert 2013-03-10 10:27 ` Thomas Petazzoni 2013-03-10 9:47 ` [Buildroot] [PATCH 4/4] directfb: fixing typo in variables Carsten Schoenert 3 siblings, 1 reply; 19+ messages in thread From: Carsten Schoenert @ 2013-03-10 9:47 UTC (permalink / raw) To: buildroot From: Carsten Schoenert <c.schoenert@gmail.com> Adding a helper string for the PXA3xx and graphics driver from Marvell and the EP9x graphics driver from Cirrus Logic. Signed-off-by: Carsten Schoenert <c.schoenert@gmail.com> --- package/directfb/Config.in | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/package/directfb/Config.in b/package/directfb/Config.in index a184568..3d22e15 100644 --- a/package/directfb/Config.in +++ b/package/directfb/Config.in @@ -49,10 +49,27 @@ config BR2_PACKAGE_DIRECTFB_MATROX config BR2_PACKAGE_DIRECTFB_PXA3XX bool "compile pxa3xx graphics driver" depends on BR2_arm + help + The Marvell PXA3xx Processor Family is a system-on-chip based + on XScale? microarchitecture. The PXA3xx processor provide + high-performance multimedia, low-power capabilities, and rich + peripheral integration. The PXA3xx Processor Family provide + enhanced features compared to the PXA27x Processor Family, and + are the first Marvell applications processors to integrate a + hardware video accelerator unit. + + http://www.marvell.com/application-processors/pxa-family/ config BR2_PACKAGE_DIRECTFB_EP9X bool "compile ep9x graphics driver" depends on BR2_arm + help + The EP93xx ARMv9 based processors from Cirrus Logic are highly + integrated systems-on-a-chip that pave the way for a multitude + of next-generation consumer and industrial electronic products. + + http://cirrus.com/en/products/arm9.html + config BR2_PACKAGE_DIRECTFB_UNICHROME bool "compile unichrome graphics driver" -- 1.7.10.4 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 3/4] directfb: expanding the help strings 2013-03-10 9:47 ` [Buildroot] [PATCH 3/4] directfb: expanding the help strings Carsten Schoenert @ 2013-03-10 10:27 ` Thomas Petazzoni 2013-03-10 12:21 ` Carsten Schoenert 0 siblings, 1 reply; 19+ messages in thread From: Thomas Petazzoni @ 2013-03-10 10:27 UTC (permalink / raw) To: buildroot Dear Carsten Schoenert, On Sun, 10 Mar 2013 10:47:37 +0100, Carsten Schoenert wrote: > From: Carsten Schoenert <c.schoenert@gmail.com> > > Adding a helper string for the PXA3xx and graphics driver from Marvell > and the EP9x graphics driver from Cirrus Logic. > > Signed-off-by: Carsten Schoenert <c.schoenert@gmail.com> > --- > package/directfb/Config.in | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > > diff --git a/package/directfb/Config.in b/package/directfb/Config.in > index a184568..3d22e15 100644 > --- a/package/directfb/Config.in > +++ b/package/directfb/Config.in > @@ -49,10 +49,27 @@ config BR2_PACKAGE_DIRECTFB_MATROX > config BR2_PACKAGE_DIRECTFB_PXA3XX > bool "compile pxa3xx graphics driver" > depends on BR2_arm > + help > + The Marvell PXA3xx Processor Family is a system-on-chip based > + on XScale? microarchitecture. The PXA3xx processor provide > + high-performance multimedia, low-power capabilities, and rich > + peripheral integration. The PXA3xx Processor Family provide > + enhanced features compared to the PXA27x Processor Family, and > + are the first Marvell applications processors to integrate a > + hardware video accelerator unit. > + > + http://www.marvell.com/application-processors/pxa-family/ Indentation is wrong. It should be one tab for "help" and one tab + two spaces for the help text. In addition to that, I'm not sure the wording of the help text is so useful. Something like "This option enables a graphics driver specific to the graphics hardware of the Marvell PXA3xx processor family", would be a bit more useful. > config BR2_PACKAGE_DIRECTFB_EP9X > bool "compile ep9x graphics driver" > depends on BR2_arm > + help > + The EP93xx ARMv9 based processors from Cirrus Logic are highly > + integrated systems-on-a-chip that pave the way for a multitude > + of next-generation consumer and industrial electronic products. > + > + http://cirrus.com/en/products/arm9.html Same comments. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 3/4] directfb: expanding the help strings 2013-03-10 10:27 ` Thomas Petazzoni @ 2013-03-10 12:21 ` Carsten Schoenert 2013-03-10 13:13 ` Thomas Petazzoni 0 siblings, 1 reply; 19+ messages in thread From: Carsten Schoenert @ 2013-03-10 12:21 UTC (permalink / raw) To: buildroot Hello Thomas, Am 10.03.2013 11:27, schrieb Thomas Petazzoni: >> + help >> + The Marvell PXA3xx Processor Family is a system-on-chip based >> + on XScale? microarchitecture. The PXA3xx processor provide >> + high-performance multimedia, low-power capabilities, and rich >> + peripheral integration. The PXA3xx Processor Family provide >> + enhanced features compared to the PXA27x Processor Family, and >> + are the first Marvell applications processors to integrate a >> + hardware video accelerator unit. >> + >> + http://www.marvell.com/application-processors/pxa-family/ > > Indentation is wrong. It should be one tab for "help" and one tab + two > spaces for the help text. Hmm, I have to check my vim settings, sorry. What about modlines in thees files? This would be helpful and it's just a one-liner on top of this files. > In addition to that, I'm not sure the wording of the help text is so > useful. Something like "This option enables a graphics driver specific > to the graphics hardware of the Marvell PXA3xx processor family", would > be a bit more useful. It have take some times for me to find out what this option is for and what kind of devices are supported by this option, so at least directfb is something for the frame buffer the most people know the options are of course depending on this frame buffer and graphic output related things. So I think it's worth to explain a little bit more than just 'it's for the Marvel PXA family foo ...'. But yes, we can discuss about the word and formulation. ;) I will rethink about that. Regards Carsten ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 3/4] directfb: expanding the help strings 2013-03-10 12:21 ` Carsten Schoenert @ 2013-03-10 13:13 ` Thomas Petazzoni 0 siblings, 0 replies; 19+ messages in thread From: Thomas Petazzoni @ 2013-03-10 13:13 UTC (permalink / raw) To: buildroot Dear Carsten Schoenert, On Sun, 10 Mar 2013 13:21:06 +0100, Carsten Schoenert wrote: > > Indentation is wrong. It should be one tab for "help" and one tab + two > > spaces for the help text. > > Hmm, I have to check my vim settings, sorry. > What about modlines in thees files? This would be helpful and it's just > a one-liner on top of this files. I don't have a very strong opinion about this, but vim would require one modeline, Emacs would require another one, some other $editor would require yet a different one. I guess it's rather up to your editor to understand that Config.in should be treated with such or such mode. > > In addition to that, I'm not sure the wording of the help text is so > > useful. Something like "This option enables a graphics driver specific > > to the graphics hardware of the Marvell PXA3xx processor family", would > > be a bit more useful. > > It have take some times for me to find out what this option is for and > what kind of devices are supported by this option, so at least directfb > is something for the frame buffer the most people know the options are > of course depending on this frame buffer and graphic output related things. > So I think it's worth to explain a little bit more than just 'it's for > the Marvel PXA family foo ...'. But yes, we can discuss about the word > and formulation. ;) > I will rethink about that. My only problem with your wording is that it was just the copy/paste describing what the processor is. The reader may not necessarily see the relation with the configuration option. So just keep your text, but at the beginning at a sentence like "This option enables a graphics driver blablabla". Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 4/4] directfb: fixing typo in variables 2013-03-10 9:47 [Buildroot] [PATCH 0/0] Updating directfb and divine Carsten Schoenert ` (2 preceding siblings ...) 2013-03-10 9:47 ` [Buildroot] [PATCH 3/4] directfb: expanding the help strings Carsten Schoenert @ 2013-03-10 9:47 ` Carsten Schoenert 2013-03-10 10:25 ` Thomas Petazzoni 3 siblings, 1 reply; 19+ messages in thread From: Carsten Schoenert @ 2013-03-10 9:47 UTC (permalink / raw) To: buildroot From: Carsten Schoenert <c.schoenert@gmail.com> Signed-off-by: Carsten Schoenert <c.schoenert@gmail.com> --- package/directfb/Config.in | 4 ++-- package/directfb/directfb.mk | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/package/directfb/Config.in b/package/directfb/Config.in index 3d22e15..f5759db 100644 --- a/package/directfb/Config.in +++ b/package/directfb/Config.in @@ -115,13 +115,13 @@ config BR2_PACKAGE_DIRECTFB_PNG default y select BR2_PACKAGE_LIBPNG -config BR2_PACKAGE_DIRECTB_DITHER_RGB16 +config BR2_PACKAGE_DIRECTFB_DITHER_RGB16 bool "enable advanced dithering of RGB16 surfaces" help Enable dithering when loading images to RGB16 surfaces. This increases the data section by 64 KBytes. -config BR2_PACKAGE_DIRECTB_TESTS +config BR2_PACKAGE_DIRECTFB_TESTS bool "build directfb tests" endif # BR2_PACKAGE_DIRECTFB diff --git a/package/directfb/directfb.mk b/package/directfb/directfb.mk index 8c701db..5ead084 100644 --- a/package/directfb/directfb.mk +++ b/package/directfb/directfb.mk @@ -108,13 +108,13 @@ else DIRECTFB_CONF_OPT += --disable-jpeg endif -ifeq ($(BR2_PACKAGE_DIRECTB_DITHER_RGB16),y) +ifeq ($(BR2_PACKAGE_DIRECTFB_DITHER_RGB16),y) DIRECTFB_CONF_OPT += --with-dither-rgb16=advanced else DIRECTFB_CONF_OPT += --with-dither-rgb16=none endif -ifeq ($(BR2_PACKAGE_DIRECTB_TESTS),y) +ifeq ($(BR2_PACKAGE_DIRECTFB_TESTS),y) DIRECTFB_CONF_OPT += --with-tests endif -- 1.7.10.4 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 4/4] directfb: fixing typo in variables 2013-03-10 9:47 ` [Buildroot] [PATCH 4/4] directfb: fixing typo in variables Carsten Schoenert @ 2013-03-10 10:25 ` Thomas Petazzoni 2013-03-10 12:23 ` Carsten Schoenert 0 siblings, 1 reply; 19+ messages in thread From: Thomas Petazzoni @ 2013-03-10 10:25 UTC (permalink / raw) To: buildroot Dear Carsten Schoenert, On Sun, 10 Mar 2013 10:47:38 +0100, Carsten Schoenert wrote: > From: Carsten Schoenert <c.schoenert@gmail.com> > > Signed-off-by: Carsten Schoenert <c.schoenert@gmail.com> > --- > package/directfb/Config.in | 4 ++-- > package/directfb/directfb.mk | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/package/directfb/Config.in b/package/directfb/Config.in > index 3d22e15..f5759db 100644 > --- a/package/directfb/Config.in > +++ b/package/directfb/Config.in > @@ -115,13 +115,13 @@ config BR2_PACKAGE_DIRECTFB_PNG > default y > select BR2_PACKAGE_LIBPNG > > -config BR2_PACKAGE_DIRECTB_DITHER_RGB16 > +config BR2_PACKAGE_DIRECTFB_DITHER_RGB16 > bool "enable advanced dithering of RGB16 surfaces" > help > Enable dithering when loading images to RGB16 surfaces. > This increases the data section by 64 KBytes. This is good, but since you're renaming configuration options, you should add something to the main Config.in.legacy: config BR2_PACKAGE_DIRECTB_DITHER_RGB16 bool "DirectFB RGB16 dithering option has been renamed" select BR2_PACKAGE_DIRECTFB_DITHER_RGB16 select BR2_LEGACY This way, users who will upgrade will be automatically notified of the option rename. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [PATCH 4/4] directfb: fixing typo in variables 2013-03-10 10:25 ` Thomas Petazzoni @ 2013-03-10 12:23 ` Carsten Schoenert 0 siblings, 0 replies; 19+ messages in thread From: Carsten Schoenert @ 2013-03-10 12:23 UTC (permalink / raw) To: buildroot Hello Thomas, Am 10.03.2013 11:25, schrieb Thomas Petazzoni: > This is good, but since you're renaming configuration options, you > should add something to the main Config.in.legacy: > > config BR2_PACKAGE_DIRECTB_DITHER_RGB16 > bool "DirectFB RGB16 dithering option has been renamed" > select BR2_PACKAGE_DIRECTFB_DITHER_RGB16 > select BR2_LEGACY > > This way, users who will upgrade will be automatically notified of the > option rename. Ahh, o.k. Don't know about this file, thanks for pointing at it. I take a look at it and rework it. Regards Carsten ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2013-04-02 21:56 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-03-10 9:47 [Buildroot] [PATCH 0/0] Updating directfb and divine Carsten Schoenert 2013-03-10 9:47 ` [Buildroot] [PATCH 1/4] directfb: bumping version to 1.6.3 Carsten Schoenert 2013-03-10 10:32 ` Thomas Petazzoni 2013-03-10 12:34 ` Carsten Schoenert 2013-03-17 13:59 ` Carsten Schoenert 2013-03-21 6:56 ` Arnout Vandecappelle 2013-03-21 18:06 ` Carsten Schoenert 2013-03-21 19:13 ` Thomas Petazzoni 2013-04-02 21:56 ` Carsten Schoenert 2013-03-10 16:50 ` Carsten Schoenert 2013-03-10 17:25 ` Thomas Petazzoni 2013-03-10 9:47 ` [Buildroot] [PATCH 2/4] divine: " Carsten Schoenert 2013-03-10 9:47 ` [Buildroot] [PATCH 3/4] directfb: expanding the help strings Carsten Schoenert 2013-03-10 10:27 ` Thomas Petazzoni 2013-03-10 12:21 ` Carsten Schoenert 2013-03-10 13:13 ` Thomas Petazzoni 2013-03-10 9:47 ` [Buildroot] [PATCH 4/4] directfb: fixing typo in variables Carsten Schoenert 2013-03-10 10:25 ` Thomas Petazzoni 2013-03-10 12:23 ` Carsten Schoenert
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.