inc file discussion

inc file discussion

[Frans Meulenbroeks]

Dear all,

I see a lot of diversity in .inc files, and I was wondering whether we
should not try to come up with some guidelines about their purpose,
what should go in it, what not etc etc.

Some observations and questions:

Some of the inc files use INC_PR whereas others do not.

Some people seem to use .inc file as a way to save bytes in the
archive and really put everything in it (including things like
DESCRIPTION, LICENSE etc etc).
While I agree that DESCRIPTION will probably not change between
versions and LICENSE is also unlikely to change, it might be more user
friendly to put them in the .bb file
(so when you open the .bb file you immediate see the basic information
of a package)
It does not really make things more work when upgrading to a new
version since I assume most people do like me and either do a git mv
or a cp from an older version (which retains the info).

What I also noticed is .inc files saying things like:
DEFAULT_PREFERENCE = "-1"
Do we want this in an inc file? I'd say an inc file is shared between
all versions; Personally I would prefer setting the -1 in the .bb
file, not in the .inc

And then there is DEPENDS in .inc files. I think there is some
potential cause of getting unneeded DEPENDS
Picture the following scenario: a new version needs an additional
package, it gets added to the DEPENDS of the .inc file and suddenly
older versions also get this DEPENDS (maybe unneeded).

I hope you get the idea.
And of course I know that .inc files are useful (e.g when it comes to
sharing python scripts etc). Then again, I feel sometimes we do too
much in them.

How do others feel about this?

Frans.

PS: did a quick grep on D_P in the inc files. See below (and yes, I
understand the reasons behind some of the, but some other cases seem
strange to me e.g what is the point of setting D_P for all versions of
a recipe to -1, I feel this does not change things compared to the
normal case (where D_P defaults to 0) (and overrides in a recipe will
set it to a positive value anyway)

binutils/mingw-binutils.inc:DEFAULT_PREFERENCE = "-1"
devio/devio-cvs.inc:DEFAULT_PREFERENCE = "-1"
dtc/dtc_git.inc:DEFAULT_PREFERENCE = "-1"
gcc/gcc-4.1.0.inc:DEFAULT_PREFERENCE = "-1"
gcc/gcc-4.3.1.inc:DEFAULT_PREFERENCE = "-99"
gcc/gcc-4.3.2.inc:DEFAULT_PREFERENCE = "-999"
gcc/gcc-4.3.3.inc:DEFAULT_PREFERENCE = "-999"
gcc/gcc-4.3.4.inc:DEFAULT_PREFERENCE = "-999"
gcc/gcc-4.4.1.inc:DEFAULT_PREFERENCE = "-999"
gcc/gcc-4.4.2.inc:DEFAULT_PREFERENCE = "-999"
gcc/gcc-4.4.4.inc:DEFAULT_PREFERENCE = "-999"
gcc/gcc-4.5.inc:DEFAULT_PREFERENCE = "-999"
gcc/gcc-svn.inc:DEFAULT_PREFERENCE = "-999"
gdb/gdb.inc:DEFAULT_PREFERENCE_avr32 = "-99"
gdb/gdbserver.inc:DEFAULT_PREFERENCE_avr32 = "-99"
gstreamer/gst-common.inc:DEFAULT_PREFERENCE = "-1"
linux/ixp4xx-kernel.inc:# DEFAULT_PREFERENCE is set automagically in
this file as
linux/ixp4xx-kernel.inc:    bb.data.setVar("DEFAULT_PREFERENCE", pref-mmac, d)
linux/ixp4xx-kernel.inc:    # bb.note("DEFAULT_PREFERENCE := %s" % (pref-mmac))
mesa/mesa-7.8.2.inc:DEFAULT_PREFERENCE_shr = "2"
mesa/mesa-dri.inc:DEFAULT_PREFERENCE = "-1"
mingw/mingw-runtime.inc:DEFAULT_PREFERENCE = "-1"
mingw/mingw-runtime.inc:DEFAULT_PREFERENCE_mingw32 = "1"
mingw/mingw-w32api.inc:DEFAULT_PREFERENCE = "-1"
mingw/mingw-w32api.inc:DEFAULT_PREFERENCE_mingw32 = "1"
python/python.inc:DEFAULT_PREFERENCE = "-26"
qt4/qt-4.6.0.inc:DEFAULT_PREFERENCE = "-1"
qt4/qt-4.6.2.inc:DEFAULT_PREFERENCE = "-1"
qt4/qt-4.6.3.inc:DEFAULT_PREFERENCE = "-1"
qt4/qt-4.7.0.inc:DEFAULT_PREFERENCE = "-1"
util-linux-ng/util-linux-ng.inc:DEFAULT_PREFERENCE = "-1"
wpa-supplicant/wpa-supplicant-0.6.inc:DEFAULT_PREFERENCE = "-2"

Re: inc file discussion

[Ulf Samuelsson]

Frans Meulenbroeks skrev:
> Dear all,
> 
> I see a lot of diversity in .inc files, and I was wondering whether we
> should not try to come up with some guidelines about their purpose,
> what should go in it, what not etc etc.
> 
> Some observations and questions:
> 
> Some of the inc files use INC_PR whereas others do not.
> 
> Some people seem to use .inc file as a way to save bytes in the
> archive and really put everything in it (including things like
> DESCRIPTION, LICENSE etc etc).
> While I agree that DESCRIPTION will probably not change between
> versions and LICENSE is also unlikely to change, it might be more user
> friendly to put them in the .bb file
> (so when you open the .bb file you immediate see the basic information
> of a package)
> It does not really make things more work when upgrading to a new
> version since I assume most people do like me and either do a git mv
> or a cp from an older version (which retains the info).
> 
> What I also noticed is .inc files saying things like:
> DEFAULT_PREFERENCE = "-1"
> Do we want this in an inc file? I'd say an inc file is shared between
> all versions; Personally I would prefer setting the -1 in the .bb
> file, not in the .inc
> 
> And then there is DEPENDS in .inc files. I think there is some
> potential cause of getting unneeded DEPENDS
> Picture the following scenario: a new version needs an additional
> package, it gets added to the DEPENDS of the .inc file and suddenly
> older versions also get this DEPENDS (maybe unneeded).
> 
> I hope you get the idea.
> And of course I know that .inc files are useful (e.g when it comes to
> sharing python scripts etc). Then again, I feel sometimes we do too
> much in them.
> 
> How do others feel about this?
> 
> Frans.
> 
> PS: did a quick grep on D_P in the inc files. See below (and yes, I
> understand the reasons behind some of the, but some other cases seem
> strange to me e.g what is the point of setting D_P for all versions of
> a recipe to -1, I feel this does not change things compared to the
> normal case (where D_P defaults to 0) (and overrides in a recipe will
> set it to a positive value anyway)
> 
> binutils/mingw-binutils.inc:DEFAULT_PREFERENCE = "-1"
> devio/devio-cvs.inc:DEFAULT_PREFERENCE = "-1"
> dtc/dtc_git.inc:DEFAULT_PREFERENCE = "-1"
> gcc/gcc-4.1.0.inc:DEFAULT_PREFERENCE = "-1"
> gcc/gcc-4.3.1.inc:DEFAULT_PREFERENCE = "-99"
> gcc/gcc-4.3.2.inc:DEFAULT_PREFERENCE = "-999"
> gcc/gcc-4.3.3.inc:DEFAULT_PREFERENCE = "-999"
> gcc/gcc-4.3.4.inc:DEFAULT_PREFERENCE = "-999"
> gcc/gcc-4.4.1.inc:DEFAULT_PREFERENCE = "-999"
> gcc/gcc-4.4.2.inc:DEFAULT_PREFERENCE = "-999"
> gcc/gcc-4.4.4.inc:DEFAULT_PREFERENCE = "-999"
> gcc/gcc-4.5.inc:DEFAULT_PREFERENCE = "-999"
> gcc/gcc-svn.inc:DEFAULT_PREFERENCE = "-999"
> gdb/gdb.inc:DEFAULT_PREFERENCE_avr32 = "-99"
> gdb/gdbserver.inc:DEFAULT_PREFERENCE_avr32 = "-99"
> gstreamer/gst-common.inc:DEFAULT_PREFERENCE = "-1"
> linux/ixp4xx-kernel.inc:# DEFAULT_PREFERENCE is set automagically in
> this file as
> linux/ixp4xx-kernel.inc:    bb.data.setVar("DEFAULT_PREFERENCE", pref-mmac, d)
> linux/ixp4xx-kernel.inc:    # bb.note("DEFAULT_PREFERENCE := %s" % (pref-mmac))
> mesa/mesa-7.8.2.inc:DEFAULT_PREFERENCE_shr = "2"
> mesa/mesa-dri.inc:DEFAULT_PREFERENCE = "-1"
> mingw/mingw-runtime.inc:DEFAULT_PREFERENCE = "-1"
> mingw/mingw-runtime.inc:DEFAULT_PREFERENCE_mingw32 = "1"
> mingw/mingw-w32api.inc:DEFAULT_PREFERENCE = "-1"
> mingw/mingw-w32api.inc:DEFAULT_PREFERENCE_mingw32 = "1"
> python/python.inc:DEFAULT_PREFERENCE = "-26"
> qt4/qt-4.6.0.inc:DEFAULT_PREFERENCE = "-1"
> qt4/qt-4.6.2.inc:DEFAULT_PREFERENCE = "-1"
> qt4/qt-4.6.3.inc:DEFAULT_PREFERENCE = "-1"
> qt4/qt-4.7.0.inc:DEFAULT_PREFERENCE = "-1"
> util-linux-ng/util-linux-ng.inc:DEFAULT_PREFERENCE = "-1"
> wpa-supplicant/wpa-supplicant-0.6.inc:DEFAULT_PREFERENCE = "-2"
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Looks good to me.
Why not start a Wiki page on guidelines and then we can update as we get
an agreement

Best Regards
Ulf Samuelsson

Re: inc file discussion

[Martin Jansa]

On Sat, Oct 09, 2010 at 11:37:49AM +0200, Frans Meulenbroeks wrote:
> Dear all,
> 
> I see a lot of diversity in .inc files, and I was wondering whether we
> should not try to come up with some guidelines about their purpose,
> what should go in it, what not etc etc.
> 
> Some observations and questions:
> 
> Some of the inc files use INC_PR whereas others do not.
> 
> Some people seem to use .inc file as a way to save bytes in the
> archive and really put everything in it (including things like
> DESCRIPTION, LICENSE etc etc).
> While I agree that DESCRIPTION will probably not change between
> versions and LICENSE is also unlikely to change, it might be more user
> friendly to put them in the .bb file
> (so when you open the .bb file you immediate see the basic information
> of a package)
> It does not really make things more work when upgrading to a new
> version since I assume most people do like me and either do a git mv
> or a cp from an older version (which retains the info).

Well it's easier to improve DESCRIPTION when it's in .inc file. And when
you want description of some package you can open .inc file instead .bb
because you usually want DESCRIPTION of program as such, not for
particular version.

I'm one of those who saves bytes by putting everything shared by all
.bbs to .inc :).

> What I also noticed is .inc files saying things like:
> DEFAULT_PREFERENCE = "-1"
> Do we want this in an inc file? I'd say an inc file is shared between
> all versions; Personally I would prefer setting the -1 in the .bb
> file, not in the .inc

The list you've attached has lots of PN-PV.inc files where it's IMHO OK
to puth DEFAULT_PREFERENCE because usually you really want to set it for
all recipes of that version.

I agree that it's strange in .inc file used in ALL versions of some
package.

> And then there is DEPENDS in .inc files. I think there is some
> potential cause of getting unneeded DEPENDS
> Picture the following scenario: a new version needs an additional
> package, it gets added to the DEPENDS of the .inc file and suddenly
> older versions also get this DEPENDS (maybe unneeded).

This case is just wrong and fault of whoever added it to .inc DEPENDS.
If only new version needs it then you should put DEPENDS += only to
recipe needing it.

But I don't see why not keep "common" DEPENDS in .inc.

> I hope you get the idea.
> And of course I know that .inc files are useful (e.g when it comes to
> sharing python scripts etc). Then again, I feel sometimes we do too
> much in them.
> 
> How do others feel about this?

I feel it the other way, I like .bb where is only require for .inc 
and checksums.

Then it's clear that all versions are built the same only with newer
sources.

I agree that it's sometimes a bit confusing when different versions
override different parts of .inc and only reliable way to see effective
recipe is to run 'bitbake -e -b recipe.bb'

Regards,
-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

Re: inc file discussion

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09-10-10 13:23, Martin Jansa wrote:
> On Sat, Oct 09, 2010 at 11:37:49AM +0200, Frans Meulenbroeks wrote:

>> And then there is DEPENDS in .inc files. I think there is some
>> potential cause of getting unneeded DEPENDS
>> Picture the following scenario: a new version needs an additional
>> package, it gets added to the DEPENDS of the .inc file and suddenly
>> older versions also get this DEPENDS (maybe unneeded).
> 
> This case is just wrong and fault of whoever added it to .inc DEPENDS.
> If only new version needs it then you should put DEPENDS += only to
> recipe needing it.
> 
> But I don't see why not keep "common" DEPENDS in .inc.

Consider the case of gst-plugins where plugins move freely between
- -base, -good, -bad and -ugly between releases.

The .inc for all plugins lists the deps to keep maintenance churn down
and to allow upgrading the recipes one by one.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMsFJfMkyGM64RGpERAoIqAJ9s21LgutdwiozXTIzHVTRBZY3EUQCggt3F
SzdoGMma8yyTCeLOywMFuKM=
=Ui1m
-----END PGP SIGNATURE-----

Re: inc file discussion

[Bernhard Guillon]

On 09.10.2010 11:37, Frans Meulenbroeks wrote:
> Dear all,
>
> I see a lot of diversity in .inc files, and I was wondering whether we
> should not try to come up with some guidelines about their purpose,
> what should go in it, what not etc etc.
>
>    

Some guidelines would be great :) (as long as they are not mandatory of 
course)

Best regards
Bernhard

Re: inc file discussion

[Frans Meulenbroeks]

Clarifying a few things.

Actually I don't care too much whether DESCRIPTION and other fields
are in the .inc file or in the bb file as long as it is done fairly
consistently.
Now it is not.
And the reason why I prefer the bb file is because not every recipe
has an .inc file, so it is a one stop shop.

I'm not proposing rigid rules. I can see a case for DEPENDS in .inc files.
Then again I actually bumped into this an hour or so after posting this.

pulseaudio can work with and without tcpwrapper, but there was no
choice forced. There was no depends, so if you happen to build
tcpwrapper before it would pick it up (but would not end up in
RDEPENDS or so).
If you did not build pulseaudio before you would not get tcpwrapper.
support/usage in pulseaudio.

One solution is to add tcpwrapper to the DEPENDS of pulseaudio.
However this was in an inc.

This gave me the following dilemma:
1 add in the recipe with _append  or +=
2 add to the inc and test the other version(s)
3 add to the inc and not test the other version(s) and assume things
work properly.
4 not do the patch.
5. remove the old recipe

I expect a lot of people would go for 3, but that *could* introduce a problem.

BTW maybe it is indeed time for BBVERSIONS or whatever it was called.

Frans

Re: inc file discussion

[Chris Larson]

On Sat, Oct 9, 2010 at 10:16 AM, Frans Meulenbroeks <
fransmeulenbroeks@gmail.com> wrote:

> This gave me the following dilemma:
> 1 add in the recipe with _append  or +=
>

Side note to lurkers: _append and _prepend should be avoided in favor of the
immediate operations (+=, .=, =., =+) unless you're doing a conditional
operation with overrides.


> 2 add to the inc and test the other version(s)
> 3 add to the inc and not test the other version(s) and assume things
> work properly.
> 4 not do the patch.
> 5. remove the old recipe
>
> I expect a lot of people would go for 3, but that *could* introduce a
> problem.
>
> BTW maybe it is indeed time for BBVERSIONS or whatever it was called.
>

BBVERSIONS is supported by 1.10, so it can be used as soon as we bump OE's
minimum bitbake version, if we choose to.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics