Re: [PATCH 1/2] glibc-initial.inc: use relative path to run configure

[Mark Hatle <mark.hatle@windriver.com>]

On 1/11/16 10:18 AM, Christopher Larson wrote:
> 
> On Mon, Jan 11, 2016 at 8:06 AM, Mark Hatle <mark.hatle@windriver.com
> <mailto:mark.hatle@windriver.com>> wrote:
> 
>     On 1/11/16 8:55 AM, Trevor Woerner wrote:
>     >
>     >
>     > On 01/11/16 00:11, Robert Yang wrote:
>     >> Avoid potential build path in output files.
>     >>
>     >> [YOCTO #8894]
>     >>
>     >> Signed-off-by: Robert Yang <liezhi.yang@windriver.com <mailto:liezhi.yang@windriver.com>>
>     >> ---
>     >>  meta/recipes-core/glibc/glibc-initial.inc |    2 +-
>     >>  1 file changed, 1 insertion(+), 1 deletion(-)
>     >>
>     >> diff --git a/meta/recipes-core/glibc/glibc-initial.inc b/meta/recipes-core/glibc/glibc-initial.inc
>     >> index 8e81f09..cb2f8dd 100644
>     >> --- a/meta/recipes-core/glibc/glibc-initial.inc
>     >> +++ b/meta/recipes-core/glibc/glibc-initial.inc
>     >> @@ -11,7 +11,7 @@ TOOLCHAIN_OPTIONS = " --sysroot=${STAGING_DIR_TCBOOTSTRAP}"
>     >>  do_configure () {
>     >>      (cd ${S} && gnu-configize) || die "failure in running gnu-configize"
>     >>      find ${S} -name "configure" | xargs touch
>     >> -    ${S}/configure --host=${TARGET_SYS} --build=${BUILD_SYS} \
>     >> +    ../git/configure --host=${TARGET_SYS} --build=${BUILD_SYS} \
>     >
>     > Although I haven't tested it, this _looks_ like it might fail quite
>     > readily. I'm sure there are some recipes that play tricks with ${S}, and
>     > what about recipes that don't pull their sources from git?
>     >
>     > Maybe something like: (cd ${S} && ./configure ...) would be better?
> 
>     That won't work since it'll run configure in the S directory.
> 
>     IF we need to use relative paths here, we need to calculate the relative path
>     from B to S and use that.  It looks like patch 2/2 already does something like
>     this using the python..  we can probably do the same.  (I don't know any reason,
>     at least for glibc, that all of the items won't be in the same "WORKDIR".  So it
>     would be relative within the WORKDIR, which SHOULD be fine.)
> 
> 
> Unless we want to specifically not support externalsrc (and therefore, devtool
> modify -x) for a particular recipe, we should probably not make the assumption
> that S and B are relative to WORKDIR :)

There ya go.  I didn't realize even with externalsrc and such that the code
wasn't copied or otherwise linked into the typical 'S' inside of WORKDIR.

So relative here is still potentially useful, but the problem being solved isn't
actually being solved in the end.  We're still ended up embedded specific paths
that are triggered QA errors because of the split S/B issue.

--Mark

> -- 
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics