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

[Daniel.]

Thanks for the advice :)

2016-11-26 13:08 GMT-02:00 Daniel. <danielhilst at gmail.com>:
> 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



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