Style issue for recipes

Style issue for recipes

[Burton, Ross]

Hi,

Quick question of style for the community to bikeshed on:  in the
general case should recipes be split into foo_1.2.bb and foo.inc, or
should they only split to bb/inc if there are multiple versions and
generally there should just be foo_1.2.bb.

Specifically I'm looking at the libunwind patch for oe-core (moving
from meta-oe) which adds libunwind_1.1.bb and libunwind.inc.
Personally I feel that splitting them up complicates packaging and
should only be done if there's actually multiple versions being used.

Ross

Re: [oe] Style issue for recipes

[Robert Yang]

On 09/04/2014 10:12 PM, Burton, Ross wrote:
> Hi,
>
> Quick question of style for the community to bikeshed on:  in the
> general case should recipes be split into foo_1.2.bb and foo.inc, or
> should they only split to bb/inc if there are multiple versions and
> generally there should just be foo_1.2.bb.

I think that put the constants in .inc is helpful for upgrading, for
example, the SUMMARY, DESCRIPTION, HOMEPAGE, SECTION, inherit and so on,
they are unlikely to change when upgrade.

// Robert

>
> Specifically I'm looking at the libunwind patch for oe-core (moving
> from meta-oe) which adds libunwind_1.1.bb and libunwind.inc.
> Personally I feel that splitting them up complicates packaging and
> should only be done if there's actually multiple versions being used.
>
> Ross
>

Re: Style issue for recipes

[Robert Yang]

On 09/04/2014 10:12 PM, Burton, Ross wrote:
> Hi,
>
> Quick question of style for the community to bikeshed on:  in the
> general case should recipes be split into foo_1.2.bb and foo.inc, or
> should they only split to bb/inc if there are multiple versions and
> generally there should just be foo_1.2.bb.

I think that put the constants in .inc is helpful for upgrading, for
example, the SUMMARY, DESCRIPTION, HOMEPAGE, SECTION, inherit and so on,
they are unlikely to change when upgrade.

// Robert

>
> Specifically I'm looking at the libunwind patch for oe-core (moving
> from meta-oe) which adds libunwind_1.1.bb and libunwind.inc.
> Personally I feel that splitting them up complicates packaging and
> should only be done if there's actually multiple versions being used.
>
> Ross
>

Re: Style issue for recipes

[Peter A. Bigot]

On 09/04/2014 10:03 AM, Robert Yang wrote:
>
> On 09/04/2014 10:12 PM, Burton, Ross wrote:
>> Hi,
>>
>> Quick question of style for the community to bikeshed on:  in the
>> general case should recipes be split into foo_1.2.bb and foo.inc, or
>> should they only split to bb/inc if there are multiple versions and
>> generally there should just be foo_1.2.bb.
>
> I think that put the constants in .inc is helpful for upgrading, for
> example, the SUMMARY, DESCRIPTION, HOMEPAGE, SECTION, inherit and so on,
> they are unlikely to change when upgrade.

I believe most of those carry over when an upgrade is simply a matter of 
renaming the recipe from foo_1.2.bb to foo_3.4.bb and changing the 
checksums.  I don't think foo.inc is warranted when only one file will 
ever include it.

I agree libunwind is a perfect example of where they can be merged into 
one file to simplify things, as long as everybody remembers to use -M 
when generating the patch.

Peter

Re: [oe] Style issue for recipes

[akuster808]

On 09/04/2014 08:03 AM, Robert Yang wrote:
>
> On 09/04/2014 10:12 PM, Burton, Ross wrote:
>> Hi,
>>
>> Quick question of style for the community to bikeshed on:  in the
>> general case should recipes be split into foo_1.2.bb and foo.inc, or
>> should they only split to bb/inc if there are multiple versions and
>> generally there should just be foo_1.2.bb.
>
> I think that put the constants in .inc is helpful for upgrading, for
> example, the SUMMARY, DESCRIPTION, HOMEPAGE, SECTION, inherit and so on,
> they are unlikely to change when upgrade.

This is the same reason why I have split a bb into two parts when I 
submit upgrades. I feel it makes reviewing easier the next time a 
package gets upgraded. Trying to find the actual changes between a file 
being deleted and the new one being added might lead to missing something.

If there are unintentional consequence by doing this, that is a problem.

- Armin

> // Robert
>
>>
>> Specifically I'm looking at the libunwind patch for oe-core (moving
>> from meta-oe) which adds libunwind_1.1.bb and libunwind.inc.
>> Personally I feel that splitting them up complicates packaging and
>> should only be done if there's actually multiple versions being used.
>>
>> Ross
>>

Re: [OE-core] Style issue for recipes

[akuster808]

On 09/04/2014 08:03 AM, Robert Yang wrote:
>
> On 09/04/2014 10:12 PM, Burton, Ross wrote:
>> Hi,
>>
>> Quick question of style for the community to bikeshed on:  in the
>> general case should recipes be split into foo_1.2.bb and foo.inc, or
>> should they only split to bb/inc if there are multiple versions and
>> generally there should just be foo_1.2.bb.
>
> I think that put the constants in .inc is helpful for upgrading, for
> example, the SUMMARY, DESCRIPTION, HOMEPAGE, SECTION, inherit and so on,
> they are unlikely to change when upgrade.

This is the same reason why I have split a bb into two parts when I 
submit upgrades. I feel it makes reviewing easier the next time a 
package gets upgraded. Trying to find the actual changes between a file 
being deleted and the new one being added might lead to missing something.

If there are unintentional consequence by doing this, that is a problem.

- Armin

> // Robert
>
>>
>> Specifically I'm looking at the libunwind patch for oe-core (moving
>> from meta-oe) which adds libunwind_1.1.bb and libunwind.inc.
>> Personally I feel that splitting them up complicates packaging and
>> should only be done if there's actually multiple versions being used.
>>
>> Ross
>>

Re: [oe] Style issue for recipes

[Enrico Scholz]

"Burton, Ross" <ross.burton@intel.com> writes:

> Quick question of style for the community to bikeshed on: in the
> general case should recipes be split into foo_1.2.bb and foo.inc, or
> should they only split to bb/inc if there are multiple versions and
> generally there should just be foo_1.2.bb.
>
> Specifically I'm looking at the libunwind patch for oe-core (moving
> from meta-oe) which adds libunwind_1.1.bb and libunwind.inc.
> Personally I feel that splitting them up complicates packaging and
> should only be done if there's actually multiple versions being used.

.inc files make sense with current packaging because they are revision
control friendly.  E.g. you can put the logic into .inc and follow its
history with 'git log' which is not possible when there are only the
versioned .bb files.

Of course, the versioned .bb files do not make much sense nowadays.
They were useful in old OE times were multiple versions of a package
were kept in parallel.



Enrico

Re: [oe] Style issue for recipes

[Burton, Ross]

On 4 September 2014 16:41, akuster808 <akuster808@gmail.com> wrote:
> This is the same reason why I have split a bb into two parts when I submit
> upgrades. I feel it makes reviewing easier the next time a package gets
> upgraded. Trying to find the actual changes between a file being deleted and
> the new one being added might lead to missing something.
>
> If there are unintentional consequence by doing this, that is a problem.

This is what git format-patch -M is for: it detects the rename and
shows a "proper" diff.

Ross

Re: [OE-core] Style issue for recipes

[Burton, Ross]

On 4 September 2014 16:41, akuster808 <akuster808@gmail.com> wrote:
> This is the same reason why I have split a bb into two parts when I submit
> upgrades. I feel it makes reviewing easier the next time a package gets
> upgraded. Trying to find the actual changes between a file being deleted and
> the new one being added might lead to missing something.
>
> If there are unintentional consequence by doing this, that is a problem.

This is what git format-patch -M is for: it detects the rename and
shows a "proper" diff.

Ross

Re: [oe] Style issue for recipes

[Burton, Ross]

On 4 September 2014 17:07, Enrico Scholz
<enrico.scholz@sigma-chemnitz.de> wrote:
> .inc files make sense with current packaging because they are revision
> control friendly.  E.g. you can put the logic into .inc and follow its
> history with 'git log' which is not possible when there are only the
> versioned .bb files.

You can follow changes to the .inc but not anything that went in and
out of the .bb, but I do concede that git not tracking the renames
directly does mean some histories are harder to track (although simple
to follow as the commit where the history stops will tell you where to
pick it up again).

Ross

Re: Style issue for recipes

[Burton, Ross]

On 4 September 2014 15:12, Burton, Ross <ross.burton@intel.com> wrote:
> Quick question of style for the community to bikeshed on:  in the
> general case should recipes be split into foo_1.2.bb and foo.inc, or
> should they only split to bb/inc if there are multiple versions and
> generally there should just be foo_1.2.bb.

Another argument against widespread inc files: they encourage the
impression that maintaining multiple versions is just a matter of
having a .inc file.  The moment you start having to put
version-specific statements into a .bb you've entered a world of pain
in keeping the .bb files in sync, moving options into the .inc as they
become used by all versions, and purging old version-specific
statements.

Ross

Re: [oe] Style issue for recipes

[Peter A. Bigot]

On 09/04/2014 11:29 AM, Burton, Ross wrote:
> On 4 September 2014 17:07, Enrico Scholz
> <enrico.scholz@sigma-chemnitz.de> wrote:
>> .inc files make sense with current packaging because they are revision
>> control friendly.  E.g. you can put the logic into .inc and follow its
>> history with 'git log' which is not possible when there are only the
>> versioned .bb files.
> You can follow changes to the .inc but not anything that went in and
> out of the .bb, but I do concede that git not tracking the renames
> directly does mean some histories are harder to track (although simple
> to follow as the commit where the history stops will tell you where to
> pick it up again).

git log --follow foo_1.2.bb handles 90% of this:

       --follow
            Continue listing the history of a file beyond renames (works 
only for a single file).

E.g. you can go all the way back to systemd 196 with:

     git log --follow meta/recipes-core/systemd/systemd_216.bb

Peter

Re: [oe] Style issue for recipes

[Enrico Scholz]

"Peter A. Bigot" <pab@pabigot.com> writes:

>>> .inc files make sense with current packaging because they are revision
>>> control friendly.  E.g. you can put the logic into .inc and follow its
>>> history with 'git log' which is not possible when there are only the
>>> versioned .bb files.
>> You can follow changes to the .inc but not anything that went in and
>> out of the .bb, but I do concede that git not tracking the renames
>> directly does mean some histories are harder to track (although simple
>> to follow as the commit where the history stops will tell you where to
>> pick it up again).
>
> git log --follow foo_1.2.bb handles 90% of this:

it's not only 'git log'; it is 'git blame' too and because git does not
support renaming of files natively, the 'git log --follow' method is
error prone and might compare the wrong files resp. fail completely when
there are too much changes.


Enrico

Re: Style issue for recipes

[Andreas Müller]

On Thu, Sep 4, 2014 at 6:34 PM, Burton, Ross <ross.burton@intel.com> wrote:
> On 4 September 2014 15:12, Burton, Ross <ross.burton@intel.com> wrote:
>> Quick question of style for the community to bikeshed on:  in the
>> general case should recipes be split into foo_1.2.bb and foo.inc, or
>> should they only split to bb/inc if there are multiple versions and
>> generally there should just be foo_1.2.bb.
>
> Another argument against widespread inc files: they encourage the
> impression that maintaining multiple versions is just a matter of
> having a .inc file.  The moment you start having to put
> version-specific statements into a .bb you've entered a world of pain
> in keeping the .bb files in sync, moving options into the .inc as they
> become used by all versions, and purging old version-specific
> statements.
>
> Ross
> --
I agree with Ross: It often took me time to find out where
functionality comes from. Inc-files do only make sense for multiple
versions of recipes or if different recipes share same code (only
example I can remember is meta-gnome gvfs/gvfs-gdu-volume-monitor
circular-dependency hack).

My feeling is that the inc-files are still from classic oe times where
we had multiple versions for many recipes and most can be merged into
recipes without loosing something.

Andreas

Re: [oe] Style issue for recipes

[Andreas Müller]

On Thu, Sep 4, 2014 at 7:00 PM, Enrico Scholz
<enrico.scholz@sigma-chemnitz.de> wrote:
> "Peter A. Bigot" <pab@pabigot.com> writes:
>
>>>> .inc files make sense with current packaging because they are revision
>>>> control friendly.  E.g. you can put the logic into .inc and follow its
>>>> history with 'git log' which is not possible when there are only the
>>>> versioned .bb files.
>>> You can follow changes to the .inc but not anything that went in and
>>> out of the .bb, but I do concede that git not tracking the renames
>>> directly does mean some histories are harder to track (although simple
>>> to follow as the commit where the history stops will tell you where to
>>> pick it up again).
>>
>> git log --follow foo_1.2.bb handles 90% of this:
>
> it's not only 'git log'; it is 'git blame' too and because git does not
> support renaming of files natively, the 'git log --follow' method is
> error prone and might compare the wrong files resp. fail completely when
> there are too much changes.
>
Did you ever use 'git blame' for few lines most recipes have?

Andreas

Re: Style issue for recipes

[Philip Balister]

On 09/04/2014 01:29 PM, Andreas Müller wrote:
> On Thu, Sep 4, 2014 at 6:34 PM, Burton, Ross <ross.burton@intel.com> wrote:
>> On 4 September 2014 15:12, Burton, Ross <ross.burton@intel.com> wrote:
>>> Quick question of style for the community to bikeshed on:  in the
>>> general case should recipes be split into foo_1.2.bb and foo.inc, or
>>> should they only split to bb/inc if there are multiple versions and
>>> generally there should just be foo_1.2.bb.
>>
>> Another argument against widespread inc files: they encourage the
>> impression that maintaining multiple versions is just a matter of
>> having a .inc file.  The moment you start having to put
>> version-specific statements into a .bb you've entered a world of pain
>> in keeping the .bb files in sync, moving options into the .inc as they
>> become used by all versions, and purging old version-specific
>> statements.
>>
>> Ross
>> --
> I agree with Ross: It often took me time to find out where
> functionality comes from. Inc-files do only make sense for multiple
> versions of recipes or if different recipes share same code (only
> example I can remember is meta-gnome gvfs/gvfs-gdu-volume-monitor
> circular-dependency hack).
> 
> My feeling is that the inc-files are still from classic oe times where
> we had multiple versions for many recipes and most can be merged into
> recipes without loosing something.

The qwt recipe uses an include file and two bb files for qt versus
qt-embedded builds. I do not know if this is wise, but it is a case not
mentioned here.

Philip




> 
> Andreas
> 

Re: [oe] Style issue for recipes

[Enrico Scholz]

Andreas Müller <schnitzeltony-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
writes:

>> it's not only 'git log'; it is 'git blame' too and because git does not
>> support renaming of files natively, the 'git log --follow' method is
>> error prone and might compare the wrong files resp. fail completely when
>> there are too much changes.
>>
> Did you ever use 'git blame' for few lines most recipes have?

In other projects (e.g. linux kernel) I am using C-x v g in emacs very
often to see when/why a certain line was added.  In some OE recipes I
would like to do the same...


Enrico

Re: Style issue for recipes

[Burton, Ross]

On 4 September 2014 18:54, Philip Balister <philip@balister.org> wrote:
> The qwt recipe uses an include file and two bb files for qt versus
> qt-embedded builds. I do not know if this is wise, but it is a case not
> mentioned here.

That seems a perfectly legitimate use of an inc as it's factoring out
common code.

Ross

Re: [oe] Style issue for recipes

[Burton, Ross]

On 4 September 2014 19:36, Enrico Scholz
<enrico.scholz@sigma-chemnitz.de> wrote:
>> Did you ever use 'git blame' for few lines most recipes have?
>
> In other projects (e.g. linux kernel) I am using C-x v g in emacs very
> often to see when/why a certain line was added.  In some OE recipes I
> would like to do the same...

Personally I find git blame totally disappointing in general, and
would love to see a "history browser" UI that let me see the history
of a line in a file without having to repeatedly git blame, get hash,
show hash, realise that change was whitespace, git blame hash^, rinse,
repeat.

If someone knows a good UI for blame-digging then please let me know!

Ross

Re: [oe] Style issue for recipes

[akuster808]

On 09/04/2014 09:26 AM, Burton, Ross wrote:
> On 4 September 2014 16:41, akuster808 <akuster808@gmail.com> wrote:
>> This is the same reason why I have split a bb into two parts when I submit
>> upgrades. I feel it makes reviewing easier the next time a package gets
>> upgraded. Trying to find the actual changes between a file being deleted and
>> the new one being added might lead to missing something.
>>
>> If there are unintentional consequence by doing this, that is a problem.
>
> This is what git format-patch -M is for: it detects the rename and
> shows a "proper" diff.
>
Ah, that is what -M does. That negates my concern.

thanks for the info.

- Armin
> Ross
>

Re: [OE-core] Style issue for recipes

[akuster808]

On 09/04/2014 09:26 AM, Burton, Ross wrote:
> On 4 September 2014 16:41, akuster808 <akuster808@gmail.com> wrote:
>> This is the same reason why I have split a bb into two parts when I submit
>> upgrades. I feel it makes reviewing easier the next time a package gets
>> upgraded. Trying to find the actual changes between a file being deleted and
>> the new one being added might lead to missing something.
>>
>> If there are unintentional consequence by doing this, that is a problem.
>
> This is what git format-patch -M is for: it detects the rename and
> shows a "proper" diff.
>
Ah, that is what -M does. That negates my concern.

thanks for the info.

- Armin
> Ross
>

Re: [oe] Style issue for recipes

[Paul Eggleton]

On Thursday 04 September 2014 15:12:02 Burton, Ross wrote:
> Quick question of style for the community to bikeshed on:  in the
> general case should recipes be split into foo_1.2.bb and foo.inc, or
> should they only split to bb/inc if there are multiple versions and
> generally there should just be foo_1.2.bb.
> 
> Specifically I'm looking at the libunwind patch for oe-core (moving
> from meta-oe) which adds libunwind_1.1.bb and libunwind.inc.
> Personally I feel that splitting them up complicates packaging and
> should only be done if there's actually multiple versions being used.

I think the conclusion we've come to is let's not have inc files just for the 
sake of having them; if we need to add them to share common functionality we 
will, but as time goes on it may be appropriate to factor some of them out. 
(Having said that I think it would cause more harm than good to go on a huge 
spree and merge a load of them away, at least at this point.)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Style issue for recipes

[Paul Eggleton]

On Thursday 04 September 2014 15:12:02 Burton, Ross wrote:
> Quick question of style for the community to bikeshed on:  in the
> general case should recipes be split into foo_1.2.bb and foo.inc, or
> should they only split to bb/inc if there are multiple versions and
> generally there should just be foo_1.2.bb.
> 
> Specifically I'm looking at the libunwind patch for oe-core (moving
> from meta-oe) which adds libunwind_1.1.bb and libunwind.inc.
> Personally I feel that splitting them up complicates packaging and
> should only be done if there's actually multiple versions being used.

I think the conclusion we've come to is let's not have inc files just for the 
sake of having them; if we need to add them to share common functionality we 
will, but as time goes on it may be appropriate to factor some of them out. 
(Having said that I think it would cause more harm than good to go on a huge 
spree and merge a load of them away, at least at this point.)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Style issue for recipes

[Mike Looijmans]

On 09/04/2014 07:29 PM, Andreas Müller wrote:
> On Thu, Sep 4, 2014 at 6:34 PM, Burton, Ross <ross.burton@intel.com> wrote:
>> On 4 September 2014 15:12, Burton, Ross <ross.burton@intel.com> wrote:
>>> Quick question of style for the community to bikeshed on:  in the
>>> general case should recipes be split into foo_1.2.bb and foo.inc, or
>>> should they only split to bb/inc if there are multiple versions and
>>> generally there should just be foo_1.2.bb.
>>
>> Another argument against widespread inc files: they encourage the
>> impression that maintaining multiple versions is just a matter of
>> having a .inc file.  The moment you start having to put
>> version-specific statements into a .bb you've entered a world of pain
>> in keeping the .bb files in sync, moving options into the .inc as they
>> become used by all versions, and purging old version-specific
>> statements.
>>
>> Ross
>> --
> I agree with Ross: It often took me time to find out where
> functionality comes from. Inc-files do only make sense for multiple
> versions of recipes or if different recipes share same code (only
> example I can remember is meta-gnome gvfs/gvfs-gdu-volume-monitor
> circular-dependency hack).
>
> My feeling is that the inc-files are still from classic oe times where
> we had multiple versions for many recipes and most can be merged into
> recipes without loosing something.

Why not take it one step further and remove the version from the bb 
filename? Only use the "versioned" filename if there actually is more 
than one version.

I'd propose that the recipe for package "foo" is always called "foo.bb". 
A "PV" setting in that file can provide the information that bitbake needs.

If there's an alternative, but not mainstream or recommended version for 
that package, it can be named "foo_1.1.bb".

That way, you can see in a glance what recipe is the default one and 
which are the "extras".

I guess for 99% of the recipes, there's only one version. It's much 
easier to track it if the filename remains constant. Yes, I know about 
git's fancy features, but...

What about the mighty simple usecase of just being able to search for 
"foo.bb" using your favorite search engine and then actually finding it 
in a public overlay repository on the web? For example, you will be able 
to find a recipe for libdvdcss by simply hunting for "libdvdcss.bb", but 
you'll have a hard time finding the hamsterdb recipe because it happens 
to be named "hamsterdb_git.bb" in that same repository.

-- 
Mike Looijmans

Re: Style issue for recipes

[Burton, Ross]

On 5 September 2014 14:58, Mike Looijmans <mike.looijmans@topic.nl> wrote:
> Why not take it one step further and remove the version from the bb
> filename? Only use the "versioned" filename if there actually is more than
> one version.

I wonder what happens if there are multiple layers in place that all
have a foo.bb with different PVs set inside them.  Do they overlay as
they share the same name, or correctly as if the version was in the
filename?

Ross

Re: [oe] Style issue for recipes

[Trevor Woerner]

On 09/04/14 15:12, Burton, Ross wrote:
> If someone knows a good UI for blame-digging then please let me know!

http://vimcasts.org/episodes/fugitive-vim-exploring-the-history-of-a-git-repository/
http://vimcasts.org/episodes/fugitive-vim-browsing-the-git-object-database/