All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: bitbake-devel@lists.openembedded.org
Cc: openembedded-devel@lists.openembedded.org,
	Aleh Arol <aleh.arol@gmail.com>
Subject: Re: source folder package dependency
Date: Wed, 01 Feb 2012 15:37:08 +0000	[thread overview]
Message-ID: <2370505.PRl1Ey1z8e@helios> (raw)
In-Reply-To: <4F26B9D3.9010709@gmail.com>

On Monday 30 January 2012 18:40:03 Aleh Arol wrote:
> I have a question I don't know how to solve:
> I have a library, for example, boost, and a part of that
> library(packaged together I mean), like bjam is required to build it.
> 
> So I have boost-X.Y.Z.bb recipe and src/boost-X.Y.Z folder(I have
> sources locally) and I need to create bjam recipe. I can make
> bjam-X.Y.Z.bb where I will refer to folder src/boost-${PV} as ${SRC_URI}
> and ${S} to find jam sources under. Then if I'll need to have 5
> different versions of boost I'll need to create 5 different versions of
> bjam recipe.... although I can use bjam.inc it will still be 5 bjam recipes.
> 
> How can I avoid that? Any way to have a version agnostic bjam recipe? Or the
> right way of doing this.

(I presume this is in the context of OpenEmbedded.) What you describe is the 
accepted way of doing things - you have a recipe for each version of the piece 
of software you're building and share the common things with a .inc file, using 
${PV} to abstract away the version. Each individual recipe ends up quite small 
with the bulk of the definitions in the inc file.

You could have a recipe which did not specify a version in the recipe filename, 
and set PV manually instead (possibly with a default); then you could set 
PV_pn-bjam = "1.1" in your distro or local configuration to pick the version. 
However I would describe that as unorthodox, and it will not work if you have 
to handle other differences between versions (e.g. renamed/moved files, 
additional configuration options, etc.) I will say however that this is more or 
less how we handle recipes built from a version control system (e.g. git); 
except in that case we set PV to something including SRCREV e.g. 
"1.0+gitr${SRCPV}" and then set SRCREV externally.

The question is will you really need 5 different versions? Or just 2-3?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre



WARNING: multiple messages have this Message-ID (diff)
From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: bitbake-devel@lists.openembedded.org
Cc: openembedded-devel@lists.openembedded.org,
	Aleh Arol <aleh.arol@gmail.com>
Subject: Re: [bitbake-devel] source folder package dependency
Date: Wed, 01 Feb 2012 15:37:08 +0000	[thread overview]
Message-ID: <2370505.PRl1Ey1z8e@helios> (raw)
In-Reply-To: <4F26B9D3.9010709@gmail.com>

On Monday 30 January 2012 18:40:03 Aleh Arol wrote:
> I have a question I don't know how to solve:
> I have a library, for example, boost, and a part of that
> library(packaged together I mean), like bjam is required to build it.
> 
> So I have boost-X.Y.Z.bb recipe and src/boost-X.Y.Z folder(I have
> sources locally) and I need to create bjam recipe. I can make
> bjam-X.Y.Z.bb where I will refer to folder src/boost-${PV} as ${SRC_URI}
> and ${S} to find jam sources under. Then if I'll need to have 5
> different versions of boost I'll need to create 5 different versions of
> bjam recipe.... although I can use bjam.inc it will still be 5 bjam recipes.
> 
> How can I avoid that? Any way to have a version agnostic bjam recipe? Or the
> right way of doing this.

(I presume this is in the context of OpenEmbedded.) What you describe is the 
accepted way of doing things - you have a recipe for each version of the piece 
of software you're building and share the common things with a .inc file, using 
${PV} to abstract away the version. Each individual recipe ends up quite small 
with the bulk of the definitions in the inc file.

You could have a recipe which did not specify a version in the recipe filename, 
and set PV manually instead (possibly with a default); then you could set 
PV_pn-bjam = "1.1" in your distro or local configuration to pick the version. 
However I would describe that as unorthodox, and it will not work if you have 
to handle other differences between versions (e.g. renamed/moved files, 
additional configuration options, etc.) I will say however that this is more or 
less how we handle recipes built from a version control system (e.g. git); 
except in that case we set PV to something including SRCREV e.g. 
"1.0+gitr${SRCPV}" and then set SRCREV externally.

The question is will you really need 5 different versions? Or just 2-3?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre



  reply	other threads:[~2012-02-01 15:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-30 15:40 source folder package dependency Aleh Arol
2012-02-01 15:37 ` Paul Eggleton [this message]
2012-02-01 15:37   ` [bitbake-devel] " Paul Eggleton
2012-02-01 20:48   ` Aleh Arol

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2370505.PRl1Ey1z8e@helios \
    --to=paul.eggleton@linux.intel.com \
    --cc=aleh.arol@gmail.com \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.