On 09/04/2014 07:29 PM, Andreas Müller wrote:
On Thu, Sep 4, 2014 at 6:34 PM, Burton, Ross <ross.bur...@intel.com> wrote:
On 4 September 2014 15:12, Burton, Ross <ross.bur...@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
--
_______________________________________________
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Reply via email to