Re: Style issue for recipes

[Mike Looijmans <mike.looijmans@topic.nl>]

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