[1/4] directfb: bumping version to 1.6.3

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(-)

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