On Fri, 2010-11-19 at 10:42 +0100, Frans Meulenbroeks wrote: > 2010/11/19 Tian, Kevin <kevin.t...@intel.com>: > >>From: Frans Meulenbroeks > >>Sent: Friday, November 19, 2010 4:45 PM > >> > >>Dear all, > >> > >>Peeking at flex I was wondering whether we should try to avoid using > >>.inc files in recipes especially if there is only one recipe. > >> > >>flex has: > >>fr...@frans-desktop:~/yocto/poky-laverne-4.0$ ls meta/recipes-devtools/flex > >>flex_2.5.35.bb flex.inc > > > > I think most .inc come from historical reason when the 1st poky repo is > > created from OE side. After that Poky chooses to maintain only one version > > which results in the fact that some .inc exists for one recipe > > Guess so. > > > >> > >>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.
git mv does not preserve history. Some of git's tools can detect renames though (e.g. git diff -M). > 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. The .inc files are kept around as it mirrors what is in OpenEmbedded. We'll continue to do that until we work out what out relationship is going to be there. I understand moving to a single .bb file would make things more logical but it would remove any ability to diff files with OE easily. > > 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) Having them in the same directory doesn't cause any complications and using the same names means that creation of a GPLv3 image is much simpler which is why we didn't rename the recipes. Cheers, Richard _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
