[yocto] inc files in recipes

[Frans Meulenbroeks]

2010/11/19 Tian, Kevin <kevin.tian at 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:
>>frans at 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.

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.
>
>>
>>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)

Frans