[OE-core] [PATCH v2] classes/waf: Fix builds when B != S

[Khem Raj]

On Mon, Dec 3, 2018 at 1:50 PM Andreas Müller <schnitzeltony at gmail.com> wrote:
>
> On Mon, Dec 3, 2018 at 9:14 PM Khem Raj <raj.khem at gmail.com> wrote:
> >
> > On Sat, Dec 1, 2018 at 4:09 PM Khem Raj <raj.khem at gmail.com> wrote:
> > >
> > > Hi Joshua
> > >
> > > There is a build failure for a2jmidid see
> > >
> > > http://errors.yoctoproject.org/Errors/Details/202833/
> > >
> > > Seem to be related can you validate
> > >
> > > On 11/30/18 7:01 PM, Joshua Watt wrote:
> > > > Waf requires that the current working directory be ${S} (the location of
> > > > the wscript) when building. Most of the time, this was true only because
> > > > B defaults to S. However, anything that changed that behavior (notably,
> > > > using externalsrc) would break the recipe. Remedy this by explicitly
> > > > changing cwd to ${S} when running waf commands. As a happy side effect,
> > > > B can be set up for "out of tree" builds to keep the source directory
> > > > clean.
> >
> > I have sent a workaround for a2jmidid to ml which means we can go
> > ahead with this change in OE-Core
> >
> > > >
> > > > Signed-off-by: Joshua Watt <JPEWhacker at gmail.com>
> > > > ---
> > > >   meta/classes/waf.bbclass | 8 +++++---
> > > >   1 file changed, 5 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/meta/classes/waf.bbclass b/meta/classes/waf.bbclass
> > > > index 19e93761b39..8e6d754c299 100644
> > > > --- a/meta/classes/waf.bbclass
> > > > +++ b/meta/classes/waf.bbclass
> > > > @@ -1,6 +1,8 @@
> > > >   # avoids build breaks when using no-static-libs.inc
> > > >   DISABLE_STATIC = ""
> > > >
> > > > +B = "${WORKDIR}/build"
> > > > +
> > > >   EXTRA_OECONF_append = " ${PACKAGECONFIG_CONFARGS}"
> > > >
> > > >   python waf_preconfigure() {
> > > > @@ -22,16 +24,16 @@ python waf_preconfigure() {
> > > >   do_configure[prefuncs] += "waf_preconfigure"
> > > >
> > > >   waf_do_configure() {
> > > > -     ${S}/waf configure --prefix=${prefix} ${WAF_EXTRA_CONF} ${EXTRA_OECONF}
> > > > +     (cd ${S} && ./waf configure -o ${B} --prefix=${prefix} ${WAF_EXTRA_CONF} ${EXTRA_OECONF})
> > > >   }
> > > >
> > > >   do_compile[progress] = "outof:^\[\s*(\d+)/\s*(\d+)\]\s+"
> > > >   waf_do_compile()  {
> > > > -     ${S}/waf build ${@oe.utils.parallel_make_argument(d, '-j%d', limit=64)}
> > > > +     (cd ${S} && ./waf build ${@oe.utils.parallel_make_argument(d, '-j%d', limit=64)})
> > > >   }
> > > >
> > > >   waf_do_install() {
> > > > -     ${S}/waf install --destdir=${D}
> > > > +     (cd ${S} && ./waf install --destdir=${D})
> > > >   }
> > > >
> > > >   EXPORT_FUNCTIONS do_configure do_compile do_install
> > > >
> > --
> Hmm - the a2jmidid shows what's going to happen: All packets shipping
> older waf need workaround hacks. This should not be the way to go
> because then we can remove waf.bbclass entirely.
>

FWIW out of all meta-openembedded layers only 1 recipe was having
this issue, while the issue you mention is real, we might have to weigh
in if we should not do this just for a handful of recipes. My
suggestion would be to change the recipes if its not a cascade

> Andreas