Bug 3095

Summary: PRINC is an undocumented feature.
Product: [Documentation] Development Manual Reporter: T OCallaghan <tocallaghan>
Component: developmentAssignee: Scott Rifenbark <srifenbark>
Status: VERIFIED FIXED QA Contact:
Severity: major    
Priority: Medium+ CC: dvhart, laurentiu.serban, sgw
Version: unspecified   
Target Milestone: 1.3 M5   
Hardware: All   
OS: Multiple   
URL: http://git.yoctoproject.org/cgit.cgi/yocto-docs/commit/?id=053e4558cc90eb1618e697394aff6d40edbeb3b1
Whiteboard: 26 Sept 2012
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: ---

Description T OCallaghan 2012-09-12 08:19:04 UTC
PRINC is only mentioned in passing in the yocto documentation, and it is used in two forms:

PRINC = "1"
and
PRINC := "${@int(PRINC) + 2}". 

neither of which are explained. though I'm guessing the second form is to guarantee PRINC works with multiple bbappends.

The only documentation is a comment in base.bbclass:
/meta/classes/base.bbclass:362:    # If PRINC is set, try and increase the PR value by the amount specified

Google highlights the issue best, search for:
site:http://www.yoctoproject.org/docs/ PRINC
Comment 1 Scott Rifenbark 2012-09-13 15:27:54 UTC
Can someone give me a rough paragraph or two describing the use for PRINC?  In comment 1 two uses are shown.  Are these the only valid uses?  What are the parameters for use? What is the general purpose for the variable, etc. 

Once I get this information I can create a glossary entry for the variable and, if appropriate, find a place in the mainstream documentation where it is used and expand on it.

Scott
Comment 2 Darren Hart 2012-09-20 21:49:44 UTC
Some discussion from the Yocto mailing list:

https://lists.yoctoproject.org/pipermail/yocto/2012-September/011411.html

>>> +PR .= ".1"
>>
>> why not
>> PRINC := "${@int(PRINC) + 1}"
>> ?
>
> I understood that the .1 adds more finer granularity instead of 
> incrementing the base PR itself.  You end up with a potential r1.2.1 
> which is still legal.

Yes but also makes order of .bbappends applied even more important.

In case one layer has
PR .= ".2"

and other
PR .= ".1"

Then it will provide r1.2.1 or r1.1.2 depending on order of bbappends
applied. Hopefully you want change order of layers to break every
upgrade path, but why not use PRINC which does not suffer from this?
 
> What happens with a r1.2 and the above @int(PRINC) + 1?

I guess it will produce r2.2

    princ = d.getVar('PRINC', True)
    if princ and princ != "0":
        pr = d.getVar('PR', True)
        pr_prefix = re.search("\D+",pr)
        prval = re.search("\d+",pr)
        if pr_prefix is None or prval is None:
            bb.error("Unable to analyse format of PR variable: %s" % pr)
        nval = int(prval.group(0)) + int(princ)
        pr = pr_prefix.group(0) + str(nval) + pr[prval.end():]
        d.setVar('PR', pr)


And another discussion:
https://lists.yoctoproject.org/pipermail/yocto/2012-July/009887.html

> PRINC := "${@int(PRINC) + 2}"

This is the correct method to use in a bbappend. Start with 1,
obviously, and bump it each time the bbappend changes.


From what I have gathered from the above is that the proper way to use PRINC is as follows:

"
PRINC will dynamically increment the PR value of a recipe while minimizing the impact of layer ordering. In order to ensure multiple bbappend files can co-exist, PRINC should be self referencing (it defaults to 0):

PRINC := "${@int(PRINC) + 2}"

It is adviseable not to use strings such as ".= '.1'" as this usage is very sensitive to layer ordering. Explicit assignments should be avoided as they cannot adequately represent multiple bbappend files.
"
Comment 3 Scott Rifenbark 2012-09-21 21:40:11 UTC
Here is a first cut at the PRINC glossary entry.  Previously emailed to Darren Hart only.  this makes it more visible to the community.  Please comment on the entry for improvements or inacurracies:

PRINC

    Causes the PR variable to dynamically increment. This incrementation increases the value of a recipe's revision (PR) while minimizing the impact of layer ordering.

    In order to ensure multiple .bbappend files can co-exist, PRINC should be self referencing. The variable defaults to 0.

    Following is an example that increments PR by two:

         PRINC := "${@int(PRINC) + 2}"
                        

    It is adviseable not to use strings such as ".= '.1'" with the variable because this usage is very sensitive to layer ordering. Explicit assignments should be avoided as they cannot adequately represent multiple .bbappend files.
Comment 4 T OCallaghan 2012-09-24 05:48:31 UTC
I just came across this, which adds another perspective to this, the INC_PR variable seems very similar to PRINC:
http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#var-INC_PR

Does PRINC duplicate INC_PR? if not, what are the situations where one is more appropriate than the other?
Comment 5 Darren Hart 2012-09-24 15:22:55 UTC
(In reply to comment #4)
> I just came across this, which adds another perspective to this, the INC_PR
> variable seems very similar to PRINC:
> http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.
> html#var-INC_PR
> 
> Does PRINC duplicate INC_PR? if not, what are the situations where one is
> more appropriate than the other?


PRINC is used to INCrement the PR value when bbappend'ing recipes.

INC_PR is used to reference, and typically append to, an INClude file's PR value. It is used when multiple recipes are built from a common include file.

The naminig is seriously unfortunately, but they perform distinct functions.
Comment 6 Scott Rifenbark 2012-09-25 18:32:53 UTC
I have been hacking away at both glossary definitions (INC_PR and PRINC) off and on for the last few days.  Here are links to the definitions I have.  Input into these definitions have come from Paul Eggleton, Scott Garman, and Darren Hart.  Further comments?

INC_PR - http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-INC_PR

PRINC - http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-PRINC

Scott
Comment 7 Darren Hart 2012-09-25 21:26:06 UTC
(In reply to comment #6)

These look good to me.
Comment 8 T OCallaghan 2012-09-26 07:14:44 UTC
Looks fine to me too.
Comment 10 Laurentiu Serban 2012-11-01 13:14:44 UTC
Verified