Message ID | 1362908858-6340-2-git-send-email-c.schoenert@gmail.com |
---|---|
State | Accepted |
Commit | 861121b4f44d596569dd0c434c4d7aac6f8815e5 |
Headers | show |
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
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
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
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
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
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
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
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
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
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+