[yocto] Extracting PV & PR from Makefile at compilation time.

Khem Raj raj.khem at gmail.com
Fri Nov 25 20:12:23 PST 2016


> On Nov 24, 2016, at 11:06 AM, Daniel. <danielhilst at gmail.com> wrote:
> 
> Instead of using SVN revision as version I'm trying to use a timestamp like:
> 
> PV = "${@time.strftime("%Y%m%d", time.gmtime())}"
> 
> Does anybody can tell me if this would taint the sstate at each day,
> making yocto compile it again? Is this safe at all?

I would recommend against it. Use PR server is better. 

> 
> Regards,
> 
> 2016-11-24 13:48 GMT-02:00 Daniel. <danielhilst at gmail.com>:
>> 2016-11-23 12:01 GMT-02:00 Bipnesh, Abhinav (Abhinav)
>> <abhinavbipnesh at avaya.com>:
>>> One quick way would be to use environment variables in both places. So you
>>> can export them before starting a build.
>>> 
>>> 
>>> 
>>> From: yocto-bounces at yoctoproject.org [mailto:yocto-bounces at yoctoproject.org]
>>> On Behalf Of Christopher Larson
>>> Sent: Wednesday, November 23, 2016 19:13
>>> To: Daniel.
>>> Cc: yocto at yoctoproject.org
>>> Subject: Re: [yocto] Extracting PV & PR from Makefile at compilation time.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Wed, Nov 23, 2016 at 6:26 AM, Daniel. <danielhilst at gmail.com> wrote:
>>> 
>>> I have a Makefile with this header
>>> 
>>> 
>>> 
>>> major = 1
>>> 
>>> minor = 0
>>> 
>>> patch = 10
>>> 
>>> release = -beta
>>> 
>>> Which compilates someting like libmylib.so.1.0.10-beta shared object.
>>> 
>>> On recipe I duplicate this information:
>>> 
>>> PV="1.0.10"
>>> 
>>> PR="-beta"
>>> 
>>> 
>>> 
>>> Is there anyway to grab that information from Makefile and setting PV & PR
>>> according to it? At compilation time? So that I only have to change at one
>>> place?
>>> 
>>> 
>>> bitbake wants to know pv/pr at parse time, long before the sources have been
>>> fetched and unpacked.
>>> --
>>> 
>>> Christopher Larson
>>> clarson at kergoth dot com
>>> Founder - BitBake, OpenEmbedded, OpenZaurus
>>> Maintainer - Tslib
>>> Senior Software Engineer, Mentor Graphics
>> 
>> Thanks guys for the reply.
>> 
>> Christopher, now I understands. It's an egg/chicken problem. So what
>> I'm asking is a bit non-sense.
>> 
>> My case is something like this:
>> 
>> We have custom board.
>> At this board some peripherals reside.
>> Some libraries sit over that peripherals.
>> I want to be able to get version of that libraries from a running
>> environment when needed. This wouldn't done by my self, but by other
>> people that have no good linux knowledge, so that need to be simple
>> like a "run this command".
>> I want to be able to get the right source code from version number.
>> I want to made package updates avaible from package feed, so that
>> running images can be updated by package manager instead of burning
>> every new image. This would make my development cycle more
>> incremental.
>> 
>> Before the first e-mail I was keeping version at makefile and
>> generating libsomething.so.X.Y.Z-release. This make it easy to grasp
>> version from library file name. But at each version the proper recipes
>> had to be edited. This is boring and error prone. I'd already build
>> packages like libsomething-1.2.3.rpm that ships libsomething-1.2.4.rpm
>> because I forgot to update the recipe.
>> 
>> So now I'm using no revision from SRC_URL (I'm using SVN). And setting
>> things like below.
>> 
>> SRCREV = "${AUTOREV}"
>> PV = "${SRCPV}"
>> PR = "r0"
>> 
>> So that recipe editing can be avoided. Since I'm using SVN the
>> revision number aways increase and I can get system update working
>> properly.
>> 
>> I'm about to read about PR service since using SVN revision as version
>> seems not a good idea for me. The libraries are only used internally
>> so I do not have to bother about versining API changes. Anyway, thanks
>> for the feedback
>> 
>> Best regards,
>> 
>> --
>> "Do or do not. There is no try"
>>  Yoda Master
> 
> 
> 
> -- 
> "Do or do not. There is no try"
>  Yoda Master
> -- 
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto




More information about the yocto mailing list