why does sysfsutils-2.1.0.bb set S = "${WORKDIR}/sysfsutils-${PV}"?
side note: the first in a small set of posts where i simply want to
clarify minor oddities i run across in oe-core, not because they have any desperate need to be fixed, but more because when i'm teaching courses in oe/yocto, i run across the occasional weirdness that puzzles students, and forces me to try to explain it, and sometimes the explanation is, "that's just silly." so here's the first one.
as i read in bitbake.conf, the default source directory for any
recipe is defined as:
S = "${WORKDIR}/${BP}"which suggests that, as long as processing a recipe ends up using that value as the source directory, there is no need for a recipe to redefine S. kind of obvious, no?
in the case of sysfsutils-2.1.0.bb, one sees the line:
S = "${WORKDIR}/sysfsutils-${PV}"
which, given the standard definitions for variables BP and PV, seems to expand into precisely the default value given in bitbake.conf.
so, unless i'm missing something, is there any actual need for that
line in the sysfsutils recipe file? is there something more subtle going on here that i don't understand?
rday
Signature · 7 lines
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================Hi Robert,
Quoted 18 lines · On Friday 23 October 2015 08:02:11 Robert P. J. Day wrote:
side note: the first in a small set of posts where i simply want to
clarify minor oddities i run across in oe-core, not because they have any desperate need to be fixed, but more because when i'm teaching courses in oe/yocto, i run across the occasional weirdness that puzzles students, and forces me to try to explain it, and sometimes the explanation is, "that's just silly." so here's the first one.as i read in bitbake.conf, the default source directory for any
recipe is defined as:S = "${WORKDIR}/${BP}"which suggests that, as long as processing a recipe ends up using that value as the source directory, there is no need for a recipe to redefine S. kind of obvious, no?
in the case of sysfsutils-2.1.0.bb, one sees the line:
Quoted 8 lines
S = "${WORKDIR}/sysfsutils-${PV}"
which, given the standard definitions for variables BP and PV, seems to expand into precisely the default value given in bitbake.conf.
so, unless i'm missing something, is there any actual need for that
line in the sysfsutils recipe file? is there something more subtle going on here that i don't understand?
I don't think so, it appears that line goes way back to the initial population of the repository. Looks like we could just drop it.
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Quoted 26 lines · Paul Eggleton
Hi Robert,
Quoted 23 lines · On Friday 23 October 2015 08:02:11 Robert P. J. Day wrote:
side note: the first in a small set of posts where i simply want to
clarify minor oddities i run across in oe-core, not because they have any desperate need to be fixed, but more because when i'm teaching courses in oe/yocto, i run across the occasional weirdness that puzzles students, and forces me to try to explain it, and sometimes the explanation is, "that's just silly." so here's the first one.as i read in bitbake.conf, the default source directory for any
recipe is defined as:S = "${WORKDIR}/${BP}"which suggests that, as long as processing a recipe ends up using that value as the source directory, there is no need for a recipe to redefine S. kind of obvious, no?
in the case of sysfsutils-2.1.0.bb, one sees the line:
S = "${WORKDIR}/sysfsutils-${PV}"
which, given the standard definitions for variables BP and PV, seems to expand into precisely the default value given in bitbake.conf.
Quoted 6 lines
Quoted 3 lines
so, unless i'm missing something, is there any actual need for that
line in the sysfsutils recipe file? is there something more subtle going on here that i don't understand?I don't think so, it appears that line goes way back to the initial population of the repository. Looks like we could just drop it.
thanks for the clarification. i realize that stuff like this is
annoyingly pedantic for developers and expert users, but it's *exactly* the kind of thing students in my classes occasionally point out and ask me to explain, and i stand there looking kind of baffled, muttering, "what the hell ..."
i'm about to update all my courseware so i'll just collect as many
of those as i can find and submit as a single patch.
rday
Signature · 7 lines
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================Quoted 32 lines · On Friday 23 October 2015 08:57:39 Robert P. J. Day wrote:
Quoted 31 lines · Paul Eggleton
Hi Robert,
Quoted 27 lines · On Friday 23 October 2015 08:02:11 Robert P. J. Day wrote:
side note: the first in a small set of posts where i simply want to
clarify minor oddities i run across in oe-core, not because they have any desperate need to be fixed, but more because when i'm teaching courses in oe/yocto, i run across the occasional weirdness that puzzles students, and forces me to try to explain it, and sometimes the explanation is, "that's just silly." so here's the first one.
as i read in bitbake.conf, the default source directory for any
recipe is defined as:
S = "${WORKDIR}/${BP}"which suggests that, as long as processing a recipe ends up using that value as the source directory, there is no need for a recipe to redefine S. kind of obvious, no?
in the case of sysfsutils-2.1.0.bb, one sees the line:
S = "${WORKDIR}/sysfsutils-${PV}"which, given the standard definitions for variables BP and PV, seems to expand into precisely the default value given in bitbake.conf.
so, unless i'm missing something, is there any actual need for that
line in the sysfsutils recipe file? is there something more subtle going on here that i don't understand?
Quoted 8 lines
Quoted 2 lines
I don't think so, it appears that line goes way back to the initial population of the repository. Looks like we could just drop it.
thanks for the clarification. i realize that stuff like this is
annoyingly pedantic for developers and expert users, but it's *exactly* the kind of thing students in my classes occasionally point out and ask me to explain, and i stand there looking kind of baffled, muttering, "what the hell ..."
Indeed, having recently been in a classroom situation at the Yocto Project Dev Day (standing at the back helpling/heckling the presenter rather than teaching ;) I know what you mean.
Quoted 2 lines
i'm about to update all my courseware so i'll just collect as many
of those as i can find and submit as a single patch.
Great, thanks!
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
On Fri, 23 Oct 2015, Paul Eggleton wrote:
... me snipped ...
Quoted 2 lines
I don't think so, it appears that line goes way back to the initial population of the repository. Looks like we could just drop it.
it *looks* like there are a number of lines like that in oe-core
that are superfluous ... some samples (which i have not verified, i just selected from brief visual inspection):
recipes-bsp/hostap/hostap-utils.inc:S = "${WORKDIR}/hostap-utils-${PV}" recipes-bsp/pcmciautils/pcmciautils.inc:S = "${WORKDIR}/pcmciautils-${PV}" recipes-connectivity/openssl/openssl.inc:S = "${WORKDIR}/openssl-${PV}" recipes-core/sysvinit/sysvinit_2.88dsf.bb:S = "${WORKDIR}/sysvinit-${PV}" recipes-core/glib-2.0/glib.inc:S = "${WORKDIR}/glib-${PV}" recipes-core/sysfsutils/sysfsutils_2.1.0.bb:S = "${WORKDIR}/sysfsutils-${PV}" recipes-devtools/mtools/mtools_3.9.9.bb:S = "${WORKDIR}/mtools-${PV}" recipes-devtools/intltool/intltool.inc:S = "${WORKDIR}/intltool-${PV}" recipes-devtools/git/git.inc:S = "${WORKDIR}/git-${PV}" recipes-extended/psmisc/psmisc.inc:S = "${WORKDIR}/psmisc-${PV}" recipes-extended/net-tools/net-tools_1.60-26.bb:S = "${WORKDIR}/net-tools-1.60" recipes-gnome/gtk+/gtk+3_3.16.6.bb:S = "${WORKDIR}/gtk+-${PV}" recipes-kernel/oprofile/oprofile_1.1.0.bb:S = "${WORKDIR}/oprofile-${PV}" recipes-multimedia/libid3tag/libid3tag_0.15.1b.bb:S = "${WORKDIR}/libid3tag-${PV}" ... etc etc ...
and probably lots more. do i have at least the right understanding that any setting of S which eventally equates to ${WORKDIR}/${BPN}-${PV} serves no useful purpose? (not sure about *-native recipes, though, i have to take a closer look at those to see if they fit the pattern.)
rday
Signature · 7 lines
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================Quoted 30 lines · On Monday 26 October 2015 06:23:09 Robert P. J. Day wrote:
On Fri, 23 Oct 2015, Paul Eggleton wrote:
... me snipped ...
Quoted 2 lines
I don't think so, it appears that line goes way back to the initial population of the repository. Looks like we could just drop it.
it *looks* like there are a number of lines like that in oe-core
that are superfluous ... some samples (which i have not verified, i just selected from brief visual inspection):recipes-bsp/hostap/hostap-utils.inc:S = "${WORKDIR}/hostap-utils-${PV}" recipes-bsp/pcmciautils/pcmciautils.inc:S = "${WORKDIR}/pcmciautils-${PV}" recipes-connectivity/openssl/openssl.inc:S = "${WORKDIR}/openssl-${PV}" recipes-core/sysvinit/sysvinit_2.88dsf.bb:S = "${WORKDIR}/sysvinit-${PV}" recipes-core/glib-2.0/glib.inc:S = "${WORKDIR}/glib-${PV}" recipes-core/sysfsutils/sysfsutils_2.1.0.bb:S = "${WORKDIR}/sysfsutils-${PV}" recipes-devtools/mtools/mtools_3.9.9.bb:S = "${WORKDIR}/mtools-${PV}" recipes-devtools/intltool/intltool.inc:S = "${WORKDIR}/intltool-${PV}" recipes-devtools/git/git.inc:S = "${WORKDIR}/git-${PV}"
recipes-extended/psmisc/psmisc.inc:S = "${WORKDIR}/psmisc-${PV}" recipes-extended/net-tools/net-tools_1.60-26.bb:S = "${WORKDIR}/net-tools-1.60" recipes-gnome/gtk+/gtk+3_3.16.6.bb:S =
"${WORKDIR}/gtk+-${PV}" recipes-kernel/oprofile/oprofile_1.1.0.bb:S = "${WORKDIR}/oprofile-${PV}" recipes-multimedia/libid3tag/libid3tag_0.15.1b.bb:S = "${WORKDIR}/libid3tag-${PV}" ... etc etc ...
Quoted 5 lines
and probably lots more. do i have at least the right understanding that any setting of S which eventally equates to ${WORKDIR}/${BPN}-${PV} serves no useful purpose? (not sure about *-native recipes, though, i have to take a closer look at those to see if they fit the pattern.)
Now, you really need to be careful with this - in some cases these files are included from other recipes where PN is not the same as it would be in the standard recipe; there it is deliberate and "cleaning it up" would actually break the other recipe. Additionally I can see above, net-tools isn't a candidate because the version part is not the same ("1.60" vs "1.60-26"). Every recipe will need to be checked.
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Quoted 37 lines · Paul Eggleton
Quoted 30 lines · On Monday 26 October 2015 06:23:09 Robert P. J. Day wrote:
On Fri, 23 Oct 2015, Paul Eggleton wrote:
... me snipped ...
Quoted 2 lines
I don't think so, it appears that line goes way back to the initial population of the repository. Looks like we could just drop it.
it *looks* like there are a number of lines like that in oe-core
that are superfluous ... some samples (which i have not verified, i just selected from brief visual inspection):recipes-bsp/hostap/hostap-utils.inc:S = "${WORKDIR}/hostap-utils-${PV}" recipes-bsp/pcmciautils/pcmciautils.inc:S = "${WORKDIR}/pcmciautils-${PV}" recipes-connectivity/openssl/openssl.inc:S = "${WORKDIR}/openssl-${PV}" recipes-core/sysvinit/sysvinit_2.88dsf.bb:S = "${WORKDIR}/sysvinit-${PV}" recipes-core/glib-2.0/glib.inc:S = "${WORKDIR}/glib-${PV}" recipes-core/sysfsutils/sysfsutils_2.1.0.bb:S = "${WORKDIR}/sysfsutils-${PV}" recipes-devtools/mtools/mtools_3.9.9.bb:S = "${WORKDIR}/mtools-${PV}" recipes-devtools/intltool/intltool.inc:S = "${WORKDIR}/intltool-${PV}" recipes-devtools/git/git.inc:S = "${WORKDIR}/git-${PV}"
recipes-extended/psmisc/psmisc.inc:S = "${WORKDIR}/psmisc-${PV}" recipes-extended/net-tools/net-tools_1.60-26.bb:S = "${WORKDIR}/net-tools-1.60" recipes-gnome/gtk+/gtk+3_3.16.6.bb:S =
"${WORKDIR}/gtk+-${PV}" recipes-kernel/oprofile/oprofile_1.1.0.bb:S = "${WORKDIR}/oprofile-${PV}" recipes-multimedia/libid3tag/libid3tag_0.15.1b.bb:S = "${WORKDIR}/libid3tag-${PV}" ... etc etc ...Quoted 5 lines
and probably lots more. do i have at least the right understanding that any setting of S which eventally equates to ${WORKDIR}/${BPN}-${PV} serves no useful purpose? (not sure about *-native recipes, though, i have to take a closer look at those to see if they fit the pattern.)
Quoted 7 lines
Now, you really need to be careful with this - in some cases these files are included from other recipes where PN is not the same as it would be in the standard recipe; there it is deliberate and "cleaning it up" would actually break the other recipe. Additionally I can see above, net-tools isn't a candidate because the version part is not the same ("1.60" vs "1.60-26"). Every recipe will need to be checked.
oh, i realize this ... i did say that this was a very cursory list i
hadn't checked carefully yet. i may or may not do any of this cleanup, i just wanted to make sure i was at least understanding the occasional redundancy correctly.
rday
Signature · 7 lines
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================