>From: Frans Meulenbroeks [mailto:[email protected]] >Sent: Friday, November 19, 2010 5:43 PM > >> >>> >>>Here the inc file could be merged into the bb file. >>>This has the advantage of having only a single file, so it is slightly >>>easier if you want to read or maintain the recipe. >> >> One advantage of not doing so is to retrieve change history in git easily. >> Version change on .bb is a rename which in git is simply a remove and >> create, while with .inc you can easily track history. This also reduces the >> commit size. > >If I am correct git mv does preserve history although the name change >makes it a little bit more difficult to track them.
I'm not sure how that works consistently. Sometimes the rename is kept while most times it doesn't happen to me. :-( > >Wrt commit size: I agree that the commit size is bigger. >If you want to minimize this you should maximize what goes into the inc. >Personally when it comes to choosing between readability, cleanness >etc and commit size, I go for the former. I'm neutral here actually. :-) But I agree with you that we should document such guideline on the wiki after it's finalized. >> >>> >>>For recipes with multiple versions (e.g. tar) it might be useful to >>>have inc files. It is really a tradeoff between easy access/reading >>>and maintainability here. >> >> There's one case we actually suggest not using .inc for multiple versions: >> both GPLv2 and GPLv3 exist for one package. That way we can avoid potential >> contamination as much as possible. > >If you want to avoid contamination as much as possible I would suggest >creating two different folders. They are two different beasts that you >want to maintain separately. > >The same also holds if you want to keep two versions because they are >e.g. functionwise very different. >Sometimes this is already done (at least in OE, there we have e.g >libsigc++-1.2 and libsigc++-2.0 and apache and apache2 directories, >also sometimes there are differently named recipes (different PN) in >the same folder, e.g. bluez and bluez4) > Perhaps that's the better approach. Thanks Kevin _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
