Thanks for the advice :) 2016-11-26 13:08 GMT-02:00 Daniel. <[email protected]>: > Now I'm using %Y%m plus PR server. > > 2016-11-26 2:12 GMT-02:00 Khem Raj <[email protected]>: >> >>> On Nov 24, 2016, at 11:06 AM, Daniel. <[email protected]> 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. <[email protected]>: >>>> 2016-11-23 12:01 GMT-02:00 Bipnesh, Abhinav (Abhinav) >>>> <[email protected]>: >>>>> One quick way would be to use environment variables in both places. So you >>>>> can export them before starting a build. >>>>> >>>>> >>>>> >>>>> From: [email protected] >>>>> [mailto:[email protected]] >>>>> On Behalf Of Christopher Larson >>>>> Sent: Wednesday, November 23, 2016 19:13 >>>>> To: Daniel. >>>>> Cc: [email protected] >>>>> Subject: Re: [yocto] Extracting PV & PR from Makefile at compilation time. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Nov 23, 2016 at 6:26 AM, Daniel. <[email protected]> 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 >>> [email protected] >>> 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 -- _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
