Bug 8542 - The S entry in the glossary does not make it clear that S can be an input
Summary: The S entry in the glossary does not make it clear that S can be an input
Status: RESOLVED FIXED
Alias: None
Product: Reference
Classification: Documentation
Component: handbook (show other bugs)
Version: 1.8
Hardware: x86 Multiple
: Medium normal
Target Milestone: 2.1 M4
Assignee: Scott Rifenbark
QA Contact:
URL:
Whiteboard: 21 March 2016: RESOLVED
Depends on:
Blocks:
 
Reported: 2015-10-19 18:27 UTC by ulfalizer
Modified: 2016-03-22 16:21 UTC (History)
4 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: Done (doc changes complete)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ulfalizer 2015-10-19 18:27:06 UTC
The glossary in the reference manual does not make it clear that S can be set by the user (recipe writer) to tell Yocto where the source is after unpacking. I suggest the following rewording (provided it's the correct interpretation - I'm still a bit confused):

"S

The location in the Build Directory where unpacked recipe source code resides. Defaults to ${WORKDIR}/${BPN}-${PV}, where ${BPN} is the base recipe name and ${PV} the recipe version. If the source tarball extracts the code to a directory called something other than ${BPN}-${PV}, or if the source code if fetched from an SCM like Git or Subversion, then S needs to be set in the recipe to tell Yocto where to find the unpacked source.
                   
As an example, assume a Source Directory top-level folder named poky and a default Build Directory at poky/build. In this case, the work directory the build system uses to keep the unpacked recipe for db would be the following by default:

     poky/build/tmp/work/qemux86-poky-linux/db/5.1.19-r3/db-5.1.19"
Comment 1 Scott Rifenbark 2015-10-21 18:09:27 UTC
Moving to 2.1.  Note to self:  I will need to back-port this to some other branches.
Comment 2 Scott Rifenbark 2015-10-21 18:40:29 UTC
Here are some more implementation notes for me when I get to this issue:

* Convey that S points to where the source has been extracted, and that the user needs to actually set it 

* adjust the example to talk about the db-5.1.1.9 subdirectory of the workdir rather than just pasting the full path
Comment 3 Scott Rifenbark 2016-02-05 22:50:59 UTC
Hi, 

Take a look at the variable description at http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#var-S.  Let me know if this is okay.

Thanks, 
Scott
Comment 4 ulfalizer 2016-02-06 10:09:46 UTC
Looks good. One more thing I'd add is an example that involves Git, because it's a very common case yet doesn't seem to get mentioned much. I'm thinking of something like the following:


For example, BitBake's [Git fetcher](http://www.yoctoproject.org/docs/2.1/bitbake-user-manual/bitbake-user-manual.html#git-fetcher) checks out source code to ${WORKDIR}/git by default. Since this path differs from the default value of S, it needs to be set explicitly as follows:

SRC_URI = "git://path/to/repo.git"
S = "${WORKDIR}/git"
Comment 5 Scott Rifenbark 2016-02-15 18:33:01 UTC
Hi, 

Take a look at the change I put into the S variable description in the glossary at http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#var-S.  Let me know if this works. 

Thanks, 
Scott
Comment 6 ulfalizer 2016-02-15 18:52:18 UTC
Looks good - thanks! Maybe it could be phrased like this to emphasize that it's a fetch-related default, though it's pretty minor:


This next example assumes a Git repository. By default, Git repositories are cloned to ${WORKDIR}/git during do_fetch. Since this path is different from the default value of S, it must be set explicitly so the source can be located:

     SRC_URI = "git://path/to/repo.git"
     S = "${WORKDIR}/git"
Comment 7 Scott Rifenbark 2016-02-15 18:59:55 UTC
Fair enough ... changed.  See http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#var-S

Thanks
Comment 8 Scott Rifenbark 2016-03-22 16:21:28 UTC
no further comments.. closing this one.