source folder package dependency

source folder package dependency

[Aleh Arol]

Hi,

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.

-- 
Best regards,
Aleh Arol

Re: source folder package dependency

[Paul Eggleton]

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

Re: [bitbake-devel] source folder package dependency

[Paul Eggleton]

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

Re: source folder package dependency

[Aleh Arol]

Ср. 01 февр. 2012 18:37:08, Paul Eggleton писал:
> 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.

Thanks you for the answer first of all.
>
> (I presume this is in the context of OpenEmbedded.) 
No, but that doesn't matter.
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.
Ok, that's more or less what I ended up with. Actually I'm ok with a
"recipe per version" way - I just gave an example of boost/bjam -
actually I have a python-ogre (if it says something to you - if not
there are several packages under one folder) and I try to
make a recipe per each incorporated package. So, I will end up twice as
much recipes if I will add another python-ogre version.
>
> The question is will you really need 5 different versions? Or just 2-3?
You are right, my question was theoretical. Just interested if there is
a better way.
>
> Cheers,
> Paul
>

Thanks again.
-- 
Best regards,
Aleh Arol