5

I have a recipe which I want to prevent from being built for the target.

I understand that, given a recipe xyz.bb, adding BBCLASSEXTEND += " native nativesdk" 'magically' allows all of the following:

$ bitbake xyz           # 1
$ bitbake nativesdk-xyz # 2
$ bitbake xyz-native    # 3

I want only numbers 2 and 3. I explicitly do NOT want number #1 to be possible (perhaps xyz has a GPL v3 license, so I never want it in the target image)

I tried naming the recipe xyz-native.bb and addingBBCLASSEXTEND += " nativesdk", but this produced buildable targets as follows.

$ bitbake xyz-native           # which is what I want
$ bitbake nativesdk-xyz-native # which is NOT what I want

The only other option I can see is to rename xyz.bb to xyz.inc and then create nativesdk-xyz.bb and xyz-native.bb with both simply requiring the common xyz.inc file.

What am I missing?

kdopen
  • 8,032
  • 7
  • 44
  • 52

3 Answers3

4

You missed adding required classes - native and nativesdk for created recipes,

$ grep -rn inherit test-layer/recipes-example/example/ 
test-layer/recipes-example/example/nativesdk-example_0.1.bb:5:inherit nativesdk
test-layer/recipes-example/example/example-native_0.1.bb:5:inherit native

Then You shall see native and nativesdk recipes:

$ bitbake -s | grep example
example-native                                        :0.1-r0                                                  
nativesdk-example                                     :0.1-r0    
lukaszgard
  • 891
  • 8
  • 16
  • OK, so you are suggesting the approach of two recipes (`-native` and `nativesdk-`) including a common `.inc` file. That's was the way I expected to go, I just hoped there'd be something simpler/cleaner. – kdopen Dec 05 '18 at 18:16
  • Actually this is the only one way (based on my knowledge), to not having the target recipe in scenario like this - by default recipe is creating for the target, so explicit *native* and *nativesdk* allows to archive that. – lukaszgard Dec 05 '18 at 18:38
  • @lukaszgard what is the difference between `native` and `nativesdk`. In both cases(native and nativesdk) the built binary/library from the recipe will be for the HOST PC(where we are running bitbake) correct? – Ravi A Oct 11 '19 at 11:45
  • @RaviA You are right both targets produce recipe packages/binary based on host architecture but main difference is that _nativesdk_ target is dedicated to produce binary to run in SDK (here is example of recipe which is used to produce [buildtools-tarball.bb](https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/meta/buildtools-tarball.bb)). But _native_ recipe target can by used by other recipe during build as dependency. – lukaszgard Oct 11 '19 at 12:41
  • @lukaszgard can you please give an example(similar to builtools-tarball.bb) for native recipe target which is used by other recipe. – Ravi A Oct 11 '19 at 13:07
  • @RaviA sure, for instance class [setuptools3.bbclass](https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/setuptools3.bbclass) class which _DEPEND's_ on _python3-setuptools-native_ recipe. – lukaszgard Oct 14 '19 at 07:11
1

If your situation is licensing then there's a better solution: just set INCOMPATIBLE_LICENSES and bitbake won't let anything that isn't compatible into the image.

If you've other mysterious reasons for wanting to refuse to allow target builds of the recipe to succeed then you can use some anonymous Python to check if class-target is in OVERRIDES and if so, raise SkipRecipe.

Ross Burton
  • 3,516
  • 13
  • 12
  • Sorry, didn't mean that to be misleading. It's not licensing, but a far more complex build issue. Basically, if the package is built for the target it screws up the building of many other things ... in weird ways. And it usually occurs because someone makes a typo in their DEPENDS (usually leaving off the -native). So I just want to make it impossible for that to happen. – kdopen Dec 06 '18 at 02:44
  • Really not sure I want to know how building one recipe for target breaks other recipes... Use SkipRecipe then. – Ross Burton Dec 06 '18 at 10:47
0

You should create 2 bitbake recipe which will include each other. First bitbake recipe will be native and nativesdk and the second will for the target. In the target bitbake recipe, you can remove the things related to the target files in the do install step like that.

xyx.bb (target recipe)

do_install_append() {
    rm -f ${D}the_files_which_you_want_do_delete
}
erenbasturk
  • 412
  • 4
  • 10
  • Thanks but, as I said, I explicitly don't want them to be able to build for the target. I'd need to clean out not just the image (my `do_install_append` would be `rm -rf ${D}`) but also the sysroot etc. – kdopen Dec 04 '18 at 23:23