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

Daniel. danielhilst at gmail.com
Sat Nov 26 07:08:02 PST 2016


Now I'm using %Y%m plus PR server.

2016-11-26 2:12 GMT-02:00 Khem Raj <raj.khem at gmail.com>:
>
>> 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
>



-- 
"Do or do not. There is no try"
  Yoda Master



More information about the yocto mailing list