Re: The simplest possible recipe


Paul Eggleton
 

Hi Paul,

On Monday 24 June 2013 17:18:05 Paul D. DeRocco wrote:
That would be to copy a single file, provided in the files subdirectory of
the recipe, into a particular place in the target tree. Is there any bbclass
that automates this? Or do I just write a recipe with a do_install function
that executes the "install" command?
There's nothing that automates this, no. On the face of it it seems
straightforward, but when installing you need to know what the permissions
should be, you may wish to name the file differently than it is named in
SRC_URI, etc. For the few cases were a recipe does need to do this it's easy
enough to just get the recipe to do everything (which is not a lot).

My only guide is 5.3.1 in the Development Manual, which performs a simple
compilation, but I'm very hazy about how recipes are interpreted, so I'd
like it if someone can tell me if I've gotten the following stuff right or
not.

SRC_URI tells bitbake what files must be gotten from somewhere and copied
somewhere else in order to carry out the build process.
To the work directory (WORKDIR) yes.

And according to the Ref Manual, the "file://" prefix tells it to fetch a
local file by searching some directories including the "files" subdirectory
next to the .bb file.
It searches FILESPATH for local files, technically, which by default includes
subdirectories named "files" and the bare name of the recipe (${BPN}) as well
as the bare name with the version separated by a dash (${BP}). So for a recipe
called example-software_2.5.bb it would search "files", "example-software", and
"example-software-2.5".

And apparently, there is a "subdir" option (whose syntax is unexplained)
which may be used to tell bitbake to put it somewhere specific
relative to ${WORKDIR}.

Is the default value of the "subdir" option the S variable?
No. By default subdir is empty - since the convention for tarballs in
free/open source software is to have a subdirectory inside the tarball
already, we don't need to extract the contents into one explicitly, we just
extract it under the WORKDIR and the contents will already be under a
subdirectory. The subdir parameter exists for those upstream tarballs where
for whatever reason the creator of the tarball has not included a
subdirectory, or has used a subdirectory which clashes with another
subdirectory name within the workdir that we already use ("image", "packages",
etc.) If you do set subdir you'll also need to set S to match it.

Is that the purpose of S, to tell bitbake where to put things that it
fetches?
Rather, it tells the build system where to find the sources after they have
been unpacked.

The Ref Manual says that S defaults to ${WORKDIR}/${PN}/${PV}
${WORKDIR}/${BP} is the default (equivalent to ${WORKDIR}/${BPN}-${PV}). This
is a common convention based on the naming of upstream tarballs, but is by no
means always the right value, hence you'll see a lot of recipes set S to the
correct value to point to whatever will be extracted from the upstream tarball
fetched by that recipe.

then the sample compile recipe sets S to ${WORKDIR}. Is that what one does
when one doesn't need to have a bunch of versioned subdirectories under
${WORKDIR}? (I'm not sure why one would ever want that, or why that would be
the default.)
If you know you're not going to unpack an archive into a subdirectory, and for
the single C file you aren't, then S can be set to ${WORKDIR} because that's
where the C file will be copied to.

So if I want to install a file somewhere, do I even need a do_install task,
or can I just set S equal to the desired target location, like
"${etcdir}/foo" and be done with it? Or is that a no-no, and should I always
use do_install?
You should always use do_install. You'll lose a bunch of flexibility trying to
do it the other way and you may break some assumptions the system makes about
what it can do with S, not to mention that the sstate code might break.

HTH.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

Join yocto@lists.yoctoproject.org to automatically receive all group messages.