is there a known issue with how SRC_URI uses OVERRIDES to locate .scc files?

is there a known issue with how SRC_URI uses OVERRIDES to locate .scc files?

[Robert P. J. Day]

  (i'm using wind river linux for this, but i'm getting the impression
that this might be coming from YP, so i'm going to ask here.)

  while i'm trying to reduce this to a minimal test case, here's the
really annoying issue i'm running into.

  i created a BSP layer, and under recipes-kernel/linux/ i created
three subdirs to hold SRC_URI content:

 * linux-windriver-3.14/         (3.14-specific)
 * linux-windriver-4.1/          (4.1-specific)
 * linux-windriver/              (applicable to either kernel)

in addition, i have subdirectories for three possible target boards,
and i also extended MACHINEOVERRIDES to define a common grouping for
two of those boards. and here's the problem.

  i have files:

 * uio.scc
 * uio.cfg
 * uio.patch

that used to apply to the two common boards, but should now apply to
all three, for all kernels.  so i used to have the directory
structure:

  linux-windriver/
    common/               (represents the 2 out of 3 related boards)
      uio.scc
      uio.cfg
      uio.patch

and the uio stuff was located just fine when building for either of
the two target boards for which "common" was my extension to
MACHINEOVERRIDES.

  now that it applies to all three boards, i did this just as a test
(as you can see, unnecessary duplication of the uio files):

  linux-windriver/
    uio.scc
    uio.cfg
    uio.patch
    common/
      uio.scc
      uio.cfg
      uio.patch

and all three boards can now build. however, when i went to get rid of
the redundant stuff and reduce it to:

  linux-windriver/
    uio.scc
    uio.cfg
    uio.patch
    common/
      ... remaining stuff that still applies only to common ...

i can still build that third board, but now the two "common" boards
fail to process the kernel fragment uio.cfg. having moved that
completely common uio content out of the subdirectory and right under
linux-windriver now breaks the boards for which there is still a
subdirectory, for no reason that i can see.

  it's as if, once the build process sees a more specific
MACHINEOVERRIDES directory from which to get content, it will no
longer look elsewhere, even above for more generically appropriate
content.

  am i misunderstanding something? it seems that the common thread
running through all my problems with this is *.cfg files at the top
level of one of these directories.

  anyone seen anything like this?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: is there a known issue with how SRC_URI uses OVERRIDES to locate .scc files?

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 4275 bytes --]

On Wed, Apr 20, 2016 at 12:42:42PM -0400, Robert P. J. Day wrote:
> 
>   (i'm using wind river linux for this, but i'm getting the impression
> that this might be coming from YP, so i'm going to ask here.)
> 
>   while i'm trying to reduce this to a minimal test case, here's the
> really annoying issue i'm running into.
> 
>   i created a BSP layer, and under recipes-kernel/linux/ i created
> three subdirs to hold SRC_URI content:
> 
>  * linux-windriver-3.14/         (3.14-specific)
>  * linux-windriver-4.1/          (4.1-specific)
>  * linux-windriver/              (applicable to either kernel)
> 
> in addition, i have subdirectories for three possible target boards,
> and i also extended MACHINEOVERRIDES to define a common grouping for
> two of those boards. and here's the problem.
> 
>   i have files:
> 
>  * uio.scc
>  * uio.cfg
>  * uio.patch
> 
> that used to apply to the two common boards, but should now apply to
> all three, for all kernels.  so i used to have the directory
> structure:
> 
>   linux-windriver/
>     common/               (represents the 2 out of 3 related boards)
>       uio.scc
>       uio.cfg
>       uio.patch
> 
> and the uio stuff was located just fine when building for either of
> the two target boards for which "common" was my extension to
> MACHINEOVERRIDES.
> 
>   now that it applies to all three boards, i did this just as a test
> (as you can see, unnecessary duplication of the uio files):
> 
>   linux-windriver/
>     uio.scc
>     uio.cfg
>     uio.patch
>     common/
>       uio.scc
>       uio.cfg
>       uio.patch
> 
> and all three boards can now build. however, when i went to get rid of
> the redundant stuff and reduce it to:
> 
>   linux-windriver/
>     uio.scc
>     uio.cfg
>     uio.patch
>     common/
>       ... remaining stuff that still applies only to common ...
> 
> i can still build that third board, but now the two "common" boards
> fail to process the kernel fragment uio.cfg. having moved that
> completely common uio content out of the subdirectory and right under
> linux-windriver now breaks the boards for which there is still a
> subdirectory, for no reason that i can see.
> 
>   it's as if, once the build process sees a more specific
> MACHINEOVERRIDES directory from which to get content, it will no
> longer look elsewhere, even above for more generically appropriate
> content.
> 
>   am i misunderstanding something? it seems that the common thread
> running through all my problems with this is *.cfg files at the top
> level of one of these directories.
> 
>   anyone seen anything like this?

Did you check FILESPATH variable to see order of directories how they
are searched?

e.g.:
$ bitbake -e sed | grep ^FILESPATH= | sed "s/FILESPATH=\"//g; s/\"$//g; s/:/\n/g;"
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/nodistro
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/nodistro
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/nodistro
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/qemux86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/qemux86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/qemux86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/qemuall
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/qemuall
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/qemuall
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/x86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/x86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/x86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/i586
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/i586
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/i586
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: is there a known issue with how SRC_URI uses OVERRIDES to locate .scc files?

[Robert P. J. Day]

[-- Attachment #1: Type: text/plain, Size: 7056 bytes --]

On Wed, 20 Apr 2016, Martin Jansa wrote:

> On Wed, Apr 20, 2016 at 12:42:42PM -0400, Robert P. J. Day wrote:
> >
> >   (i'm using wind river linux for this, but i'm getting the impression
> > that this might be coming from YP, so i'm going to ask here.)
> >
> >   while i'm trying to reduce this to a minimal test case, here's the
> > really annoying issue i'm running into.
> >
> >   i created a BSP layer, and under recipes-kernel/linux/ i created
> > three subdirs to hold SRC_URI content:
> >
> >  * linux-windriver-3.14/         (3.14-specific)
> >  * linux-windriver-4.1/          (4.1-specific)
> >  * linux-windriver/              (applicable to either kernel)
> >
> > in addition, i have subdirectories for three possible target boards,
> > and i also extended MACHINEOVERRIDES to define a common grouping for
> > two of those boards. and here's the problem.
> >
> >   i have files:
> >
> >  * uio.scc
> >  * uio.cfg
> >  * uio.patch
> >
> > that used to apply to the two common boards, but should now apply to
> > all three, for all kernels.  so i used to have the directory
> > structure:
> >
> >   linux-windriver/
> >     common/               (represents the 2 out of 3 related boards)
> >       uio.scc
> >       uio.cfg
> >       uio.patch
> >
> > and the uio stuff was located just fine when building for either of
> > the two target boards for which "common" was my extension to
> > MACHINEOVERRIDES.
> >
> >   now that it applies to all three boards, i did this just as a test
> > (as you can see, unnecessary duplication of the uio files):
> >
> >   linux-windriver/
> >     uio.scc
> >     uio.cfg
> >     uio.patch
> >     common/
> >       uio.scc
> >       uio.cfg
> >       uio.patch
> >
> > and all three boards can now build. however, when i went to get rid of
> > the redundant stuff and reduce it to:
> >
> >   linux-windriver/
> >     uio.scc
> >     uio.cfg
> >     uio.patch
> >     common/
> >       ... remaining stuff that still applies only to common ...
> >
> > i can still build that third board, but now the two "common" boards
> > fail to process the kernel fragment uio.cfg. having moved that
> > completely common uio content out of the subdirectory and right under
> > linux-windriver now breaks the boards for which there is still a
> > subdirectory, for no reason that i can see.
> >
> >   it's as if, once the build process sees a more specific
> > MACHINEOVERRIDES directory from which to get content, it will no
> > longer look elsewhere, even above for more generically appropriate
> > content.
> >
> >   am i misunderstanding something? it seems that the common thread
> > running through all my problems with this is *.cfg files at the top
> > level of one of these directories.
> >
> >   anyone seen anything like this?
>
> Did you check FILESPATH variable to see order of directories how they
> are searched?
>
> e.g.:
> $ bitbake -e sed | grep ^FILESPATH= | sed "s/FILESPATH=\"//g; s/\"$//g; s/:/\n/g;"
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/nodistro
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/nodistro
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/nodistro
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/qemux86
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/qemux86
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/qemux86
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/qemuall
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/qemuall
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/qemuall
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/x86
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/x86
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/x86
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/i586
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/i586
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/i586
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/

  yes, and they all look fine, but here's the latest development which
should clarify things.

  here's the structure of the generic linux-windriver/ directory,
under which the search should look for anything which hasn't matched
anything more specific in terms of a kernel version:

linux-windriver/
├── 0001-UIO-support-for-FPGA-select-CONFIG_UIO_XII_FPGA-y.patch
├  mxeiii
   ... mxe board specific stuff but *no* uio-related stuff
├── uio.cfg
└── uio.scc

  so what we have is the UIO stuff *immediately* under
linux-windriver/, which is where it should be found (there is no other
UIO content anywhere else in the recipe directory).

  after doing the configure, here's the content of
bitbake_build/tmp/work-shared/ax/kernel-source/.kernel-meta/cfg/standard/ax/config.log:

[INFO] Sanitizing .kernel-meta/cfg/ax/new_board.cfg
[INFO] Sanitizing .kernel-meta/cfg/linux-windriver/uio.cfg
[INFO] Sanitizing .kernel-meta/cfg/kernel-meta/cfg/systemd.cfg

note carefully how that second line shows clearly where the uio.cfg
file is being found(?): linux-windriver/uio.cfg

and that's for the board that works.

  however, for the second board (the mxeiii for which there *is* a
subdirectory that should be examined), here's the equivalent
config.log file:

[INFO] Sanitizing .kernel-meta/cfg/mxeiii/new_board.cfg
[INFO] Sanitizing .kernel-meta/cfg/uio.cfg
[ERROR] Kern frag .kernel-meta/cfg/uio.cfg does not exist

note the difference in the second line in the two cases -- the
subdirectory name "linux-windriver" has disappeared, hence the second
case fails miserably in locating the config fragment file uio.cfg.

  it's as if (and i'm just making this up now) the fact that a more
specific "mxeiii" subdirectory under linux-windriver/ somehow screws
up the search process. (if i redundantly duplicate those UIO files in
the mxeiii/ subdirectory, then everything works fine, but that should
*not* be necessary.)

  is there something about the SRC_URI search order that i'm unaware
of? should each SRC_URI item start a brand new, independent search?
i've been fighting with this for a while, and it simply makes no sense
to me.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: is there a known issue with how SRC_URI uses OVERRIDES to locate .scc files?

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 8203 bytes --]

On Wed, Apr 20, 2016 at 2:31 PM, Robert P. J. Day <rpjday@crashcourse.ca>
wrote:

> On Wed, 20 Apr 2016, Martin Jansa wrote:
>
> > On Wed, Apr 20, 2016 at 12:42:42PM -0400, Robert P. J. Day wrote:
> > >
> > >   (i'm using wind river linux for this, but i'm getting the impression
> > > that this might be coming from YP, so i'm going to ask here.)
> > >
> > >   while i'm trying to reduce this to a minimal test case, here's the
> > > really annoying issue i'm running into.
> > >
> > >   i created a BSP layer, and under recipes-kernel/linux/ i created
> > > three subdirs to hold SRC_URI content:
> > >
> > >  * linux-windriver-3.14/         (3.14-specific)
> > >  * linux-windriver-4.1/          (4.1-specific)
> > >  * linux-windriver/              (applicable to either kernel)
> > >
> > > in addition, i have subdirectories for three possible target boards,
> > > and i also extended MACHINEOVERRIDES to define a common grouping for
> > > two of those boards. and here's the problem.
> > >
> > >   i have files:
> > >
> > >  * uio.scc
> > >  * uio.cfg
> > >  * uio.patch
> > >
> > > that used to apply to the two common boards, but should now apply to
> > > all three, for all kernels.  so i used to have the directory
> > > structure:
> > >
> > >   linux-windriver/
> > >     common/               (represents the 2 out of 3 related boards)
> > >       uio.scc
> > >       uio.cfg
> > >       uio.patch
> > >
> > > and the uio stuff was located just fine when building for either of
> > > the two target boards for which "common" was my extension to
> > > MACHINEOVERRIDES.
> > >
> > >   now that it applies to all three boards, i did this just as a test
> > > (as you can see, unnecessary duplication of the uio files):
> > >
> > >   linux-windriver/
> > >     uio.scc
> > >     uio.cfg
> > >     uio.patch
> > >     common/
> > >       uio.scc
> > >       uio.cfg
> > >       uio.patch
> > >
> > > and all three boards can now build. however, when i went to get rid of
> > > the redundant stuff and reduce it to:
> > >
> > >   linux-windriver/
> > >     uio.scc
> > >     uio.cfg
> > >     uio.patch
> > >     common/
> > >       ... remaining stuff that still applies only to common ...
> > >
> > > i can still build that third board, but now the two "common" boards
> > > fail to process the kernel fragment uio.cfg. having moved that
> > > completely common uio content out of the subdirectory and right under
> > > linux-windriver now breaks the boards for which there is still a
> > > subdirectory, for no reason that i can see.
> > >
> > >   it's as if, once the build process sees a more specific
> > > MACHINEOVERRIDES directory from which to get content, it will no
> > > longer look elsewhere, even above for more generically appropriate
> > > content.
> > >
> > >   am i misunderstanding something? it seems that the common thread
> > > running through all my problems with this is *.cfg files at the top
> > > level of one of these directories.
> > >
> > >   anyone seen anything like this?
> >
> > Did you check FILESPATH variable to see order of directories how they
> > are searched?
> >
> > e.g.:
> > $ bitbake -e sed | grep ^FILESPATH= | sed "s/FILESPATH=\"//g; s/\"$//g;
> s/:/\n/g;"
> >
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/nodistro
> >
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/nodistro
> >
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/nodistro
> >
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/qemux86
> > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/qemux86
> >
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/qemux86
> >
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/qemuall
> > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/qemuall
> >
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/qemuall
> >
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/x86
> > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/x86
> > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/x86
> >
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/i586
> > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/i586
> > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/i586
> > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/
> > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/
> > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/
>
>   yes, and they all look fine, but here's the latest development which
> should clarify things.
>
>   here's the structure of the generic linux-windriver/ directory,
> under which the search should look for anything which hasn't matched
> anything more specific in terms of a kernel version:
>
> linux-windriver/
> ├── 0001-UIO-support-for-FPGA-select-CONFIG_UIO_XII_FPGA-y.patch
> ├  mxeiii
>    ... mxe board specific stuff but *no* uio-related stuff
> ├── uio.cfg
> └── uio.scc
>
>   so what we have is the UIO stuff *immediately* under
> linux-windriver/, which is where it should be found (there is no other
> UIO content anywhere else in the recipe directory).
>
>   after doing the configure, here's the content of
>
> bitbake_build/tmp/work-shared/ax/kernel-source/.kernel-meta/cfg/standard/ax/config.log:
>
> [INFO] Sanitizing .kernel-meta/cfg/ax/new_board.cfg
> [INFO] Sanitizing .kernel-meta/cfg/linux-windriver/uio.cfg
> [INFO] Sanitizing .kernel-meta/cfg/kernel-meta/cfg/systemd.cfg
>
> note carefully how that second line shows clearly where the uio.cfg
> file is being found(?): linux-windriver/uio.cfg
>
> and that's for the board that works.
>
>   however, for the second board (the mxeiii for which there *is* a
> subdirectory that should be examined), here's the equivalent
> config.log file:
>
> [INFO] Sanitizing .kernel-meta/cfg/mxeiii/new_board.cfg
> [INFO] Sanitizing .kernel-meta/cfg/uio.cfg
> [ERROR] Kern frag .kernel-meta/cfg/uio.cfg does not exist
>
> note the difference in the second line in the two cases -- the
> subdirectory name "linux-windriver" has disappeared, hence the second
> case fails miserably in locating the config fragment file uio.cfg.
>
>   it's as if (and i'm just making this up now) the fact that a more
> specific "mxeiii" subdirectory under linux-windriver/ somehow screws
> up the search process. (if i redundantly duplicate those UIO files in
> the mxeiii/ subdirectory, then everything works fine, but that should
> *not* be necessary.)
>
>   is there something about the SRC_URI search order that i'm unaware
> of? should each SRC_URI item start a brand new, independent search?
> i've been fighting with this for a while, and it simply makes no sense
> to me.
>

You haven't supplied your SRC_URI in the question ... what does it look
like ?

It has no relation to the SRC_URI, probably a run of the mill bug in the
processing code.
I'd suggest taking it up with Wind River support.

Alternatively, if you have this somewhere that I clone and launch a test
build, I can
help you out .. but I won't be able to easily reproduce that situation from
scratch.

Cheers,

Bruce


>
> rday
>
> --
>
> ========================================================================
> Robert P. J. Day                                 Ottawa, Ontario, CANADA
>                         http://crashcourse.ca
>
> Twitter:                                       http://twitter.com/rpjday
> LinkedIn:                               http://ca.linkedin.com/in/rpjday
> ========================================================================
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>


-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

[-- Attachment #2: Type: text/html, Size: 10466 bytes --]

Re: is there a known issue with how SRC_URI uses OVERRIDES to locate .scc files?

[Robert P. J. Day]

On Wed, 20 Apr 2016, Martin Jansa wrote:

> On Wed, Apr 20, 2016 at 12:42:42PM -0400, Robert P. J. Day wrote:
> >
> >   (i'm using wind river linux for this, but i'm getting the impression
> > that this might be coming from YP, so i'm going to ask here.)
> >
> >   while i'm trying to reduce this to a minimal test case, here's the
> > really annoying issue i'm running into.
> >
> >   i created a BSP layer, and under recipes-kernel/linux/ i created
> > three subdirs to hold SRC_URI content:
> >
> >  * linux-windriver-3.14/         (3.14-specific)
> >  * linux-windriver-4.1/          (4.1-specific)
> >  * linux-windriver/              (applicable to either kernel)
> >
> > in addition, i have subdirectories for three possible target boards,
> > and i also extended MACHINEOVERRIDES to define a common grouping for
> > two of those boards. and here's the problem.
> >
> >   i have files:
> >
> >  * uio.scc
> >  * uio.cfg
> >  * uio.patch
> >
> > that used to apply to the two common boards, but should now apply to
> > all three, for all kernels.  so i used to have the directory
> > structure:
> >
> >   linux-windriver/
> >     common/               (represents the 2 out of 3 related boards)
> >       uio.scc
> >       uio.cfg
> >       uio.patch
> >
> > and the uio stuff was located just fine when building for either of
> > the two target boards for which "common" was my extension to
> > MACHINEOVERRIDES.
> >
> >   now that it applies to all three boards, i did this just as a test
> > (as you can see, unnecessary duplication of the uio files):
> >
> >   linux-windriver/
> >     uio.scc
> >     uio.cfg
> >     uio.patch
> >     common/
> >       uio.scc
> >       uio.cfg
> >       uio.patch
> >
> > and all three boards can now build. however, when i went to get rid of
> > the redundant stuff and reduce it to:
> >
> >   linux-windriver/
> >     uio.scc
> >     uio.cfg
> >     uio.patch
> >     common/
> >       ... remaining stuff that still applies only to common ...
> >
> > i can still build that third board, but now the two "common" boards
> > fail to process the kernel fragment uio.cfg. having moved that
> > completely common uio content out of the subdirectory and right under
> > linux-windriver now breaks the boards for which there is still a
> > subdirectory, for no reason that i can see.
> >
> >   it's as if, once the build process sees a more specific
> > MACHINEOVERRIDES directory from which to get content, it will no
> > longer look elsewhere, even above for more generically appropriate
> > content.
> >
> >   am i misunderstanding something? it seems that the common thread
> > running through all my problems with this is *.cfg files at the top
> > level of one of these directories.
> >
> >   anyone seen anything like this?
>
> Did you check FILESPATH variable to see order of directories how they
> are searched?
>
> e.g.:
> $ bitbake -e sed | grep ^FILESPATH= | sed "s/FILESPATH=\"//g; s/\"$//g; s/:/\n/g;"
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/nodistro
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/nodistro
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/nodistro
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/qemux86
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/qemux86
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/qemux86
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/qemuall
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/qemuall
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/qemuall
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/x86
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/x86
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/x86
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/i586
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/i586
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/i586
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/
> /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/

  BTW, my (heavily-snipped) FILESPATH includes:

/home/rpjday/swe/recipes-kernel/linux/linux-windriver-4.1/mxeiii
/home/rpjday/swe/recipes-kernel/linux/linux-windriver/mxeiii
/home/rpjday/swe/recipes-kernel/linux/linux-windriver-4.1/
/home/rpjday/swe/recipes-kernel/linux/linux-windriver/

i chopped out quite a number of lines that have no value to this
build, but you can see the search order, particularly the second and
fourth lines:

/home/rpjday/swe/recipes-kernel/linux/linux-windriver/mxeiii
/home/rpjday/swe/recipes-kernel/linux/linux-windriver/

which, as i understand it, means it will look in that mxeiii-specific
directory and, failing that, then look in the higher level one. that's
how i'm reading FILESPATH, what am i somehow misinterpreting?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: is there a known issue with how SRC_URI uses OVERRIDES to locate .scc files?

[Robert P. J. Day]

[-- Attachment #1: Type: text/plain, Size: 9250 bytes --]

On Wed, 20 Apr 2016, Bruce Ashfield wrote:

>
>
> On Wed, Apr 20, 2016 at 2:31 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>       On Wed, 20 Apr 2016, Martin Jansa wrote:
>
>       > On Wed, Apr 20, 2016 at 12:42:42PM -0400, Robert P. J. Day wrote:
>       > >
>       > >   (i'm using wind river linux for this, but i'm getting the impression
>       > > that this might be coming from YP, so i'm going to ask here.)
>       > >
>       > >   while i'm trying to reduce this to a minimal test case, here's the
>       > > really annoying issue i'm running into.
>       > >
>       > >   i created a BSP layer, and under recipes-kernel/linux/ i created
>       > > three subdirs to hold SRC_URI content:
>       > >
>       > >  * linux-windriver-3.14/         (3.14-specific)
>       > >  * linux-windriver-4.1/          (4.1-specific)
>       > >  * linux-windriver/              (applicable to either kernel)
>       > >
>       > > in addition, i have subdirectories for three possible target boards,
>       > > and i also extended MACHINEOVERRIDES to define a common grouping for
>       > > two of those boards. and here's the problem.
>       > >
>       > >   i have files:
>       > >
>       > >  * uio.scc
>       > >  * uio.cfg
>       > >  * uio.patch
>       > >
>       > > that used to apply to the two common boards, but should now apply to
>       > > all three, for all kernels.  so i used to have the directory
>       > > structure:
>       > >
>       > >   linux-windriver/
>       > >     common/               (represents the 2 out of 3 related boards)
>       > >       uio.scc
>       > >       uio.cfg
>       > >       uio.patch
>       > >
>       > > and the uio stuff was located just fine when building for either of
>       > > the two target boards for which "common" was my extension to
>       > > MACHINEOVERRIDES.
>       > >
>       > >   now that it applies to all three boards, i did this just as a test
>       > > (as you can see, unnecessary duplication of the uio files):
>       > >
>       > >   linux-windriver/
>       > >     uio.scc
>       > >     uio.cfg
>       > >     uio.patch
>       > >     common/
>       > >       uio.scc
>       > >       uio.cfg
>       > >       uio.patch
>       > >
>       > > and all three boards can now build. however, when i went to get rid of
>       > > the redundant stuff and reduce it to:
>       > >
>       > >   linux-windriver/
>       > >     uio.scc
>       > >     uio.cfg
>       > >     uio.patch
>       > >     common/
>       > >       ... remaining stuff that still applies only to common ...
>       > >
>       > > i can still build that third board, but now the two "common" boards
>       > > fail to process the kernel fragment uio.cfg. having moved that
>       > > completely common uio content out of the subdirectory and right under
>       > > linux-windriver now breaks the boards for which there is still a
>       > > subdirectory, for no reason that i can see.
>       > >
>       > >   it's as if, once the build process sees a more specific
>       > > MACHINEOVERRIDES directory from which to get content, it will no
>       > > longer look elsewhere, even above for more generically appropriate
>       > > content.
>       > >
>       > >   am i misunderstanding something? it seems that the common thread
>       > > running through all my problems with this is *.cfg files at the top
>       > > level of one of these directories.
>       > >
>       > >   anyone seen anything like this?
>       >
>       > Did you check FILESPATH variable to see order of directories how they
>       > are searched?
>       >
>       > e.g.:
>       > $ bitbake -e sed | grep ^FILESPATH= | sed "s/FILESPATH=\"//g; s/\"$//g; s/:/\n/g;"
>       > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/nodistro
>       > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/nodistro
>       > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/nodistro
>       > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/qemux86
>       > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/qemux86
>       > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/qemux86
>       > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/qemuall
>       > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/qemuall
>       > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/qemuall
>       > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/x86
>       > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/x86
>       > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/x86
>       > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/i586
>       > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/i586
>       > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/i586
>       > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/
>       > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/
>       > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/
>
>   yes, and they all look fine, but here's the latest development which
> should clarify things.
>
>   here's the structure of the generic linux-windriver/ directory,
> under which the search should look for anything which hasn't matched
> anything more specific in terms of a kernel version:
>
> linux-windriver/
> ├── 0001-UIO-support-for-FPGA-select-CONFIG_UIO_XII_FPGA-y.patch
> ├  mxeiii
>    ... mxe board specific stuff but *no* uio-related stuff
> ├── uio.cfg
> └── uio.scc
>
>   so what we have is the UIO stuff *immediately* under
> linux-windriver/, which is where it should be found (there is no other
> UIO content anywhere else in the recipe directory).
>
>   after doing the configure, here's the content of
> bitbake_build/tmp/work-shared/ax/kernel-source/.kernel-meta/cfg/standard/ax/config.log:
>
> [INFO] Sanitizing .kernel-meta/cfg/ax/new_board.cfg
> [INFO] Sanitizing .kernel-meta/cfg/linux-windriver/uio.cfg
> [INFO] Sanitizing .kernel-meta/cfg/kernel-meta/cfg/systemd.cfg
>
> note carefully how that second line shows clearly where the uio.cfg
> file is being found(?): linux-windriver/uio.cfg
>
> and that's for the board that works.
>
>   however, for the second board (the mxeiii for which there *is* a
> subdirectory that should be examined), here's the equivalent
> config.log file:
>
> [INFO] Sanitizing .kernel-meta/cfg/mxeiii/new_board.cfg
> [INFO] Sanitizing .kernel-meta/cfg/uio.cfg
> [ERROR] Kern frag .kernel-meta/cfg/uio.cfg does not exist
>
> note the difference in the second line in the two cases -- the
> subdirectory name "linux-windriver" has disappeared, hence the second
> case fails miserably in locating the config fragment file uio.cfg.
>
>   it's as if (and i'm just making this up now) the fact that a more
> specific "mxeiii" subdirectory under linux-windriver/ somehow screws
> up the search process. (if i redundantly duplicate those UIO files in
> the mxeiii/ subdirectory, then everything works fine, but that should
> *not* be necessary.)
>
>   is there something about the SRC_URI search order that i'm unaware
> of? should each SRC_URI item start a brand new, independent search?
> i've been fighting with this for a while, and it simply makes no sense
> to me.
>
> You haven't supplied your SRC_URI in the question ... what does it
> look like ?

the first part is:

SRC_URI += " \
        file://new_board.scc \
        file://uio.scc \
"

there's more but the above is where the problem appears.

> It has no relation to the SRC_URI, probably a run of the mill bug in
> the processing code. I'd suggest taking it up with Wind River
> support.

  already have, the person i chatted with muttered something about
backtracking to YP code which is why i thought i would ask here. i've
seen problems related to this before which seem related to kernel
config fragment files being at the very top of a kernel recipe
subdirectory.

> Alternatively, if you have this somewhere that I clone and launch a
> test build, I can help you out .. but I won't be able to easily
> reproduce that situation from scratch.

  i'm building a minimal test case to see if i can duplicate this. but
i've definitely reproduced this issue several times today alone.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: is there a known issue with how SRC_URI uses OVERRIDES to locate .scc files?

[Robert P. J. Day]

[-- Attachment #1: Type: text/plain, Size: 4404 bytes --]


  ok, i've narrowed this down to a fairly trivial case, so allow me to
describe it. first, in my kernel recipes directory structure, i have
subdirectories:

linux-windriver-3.14/
linux-windriver-4.1/
linux-windriver/

and that last directory contains:

$ tree linux-windriver
linux-windriver
├── mxeiii            (target board in question)
│   ├── mm.patch
│   └── mm.scc
├── ssd_sil.cfg
├── ssd_sil.patch
├── ssd_sil.scc
├── uio.cfg
├── uio.patch
└── uio.scc

  so, that directory contains two SRC_URI items *immediately*
underneath, and one more further under mxeiii/, which is my target
board.

  first experiment:

SRC_URI += " \
        file://new_board.scc \           (adding this has no effect)
        file://uio.scc \
        file://ssd_sil.scc \
"

so (other than new_board.scc), i am processing only .scc files
immediately under linux-windriver/. and that works fine:

  $ make linux-windriver.configure

and i can list
bitbake_build/tmp/work-shared/mxeiii/kernel-source/.kernel-meta/cfg/standard/mxeiii/config.log:

[INFO] Sanitizing .kernel-meta/cfg/mxeiii/new_board.cfg
[INFO] Sanitizing
.kernel-meta/cfg/scratch/obj/home/rpjday/swe/recipes-kernel/linux/linux-windriver/uio.cfg
[INFO] Sanitizing
.kernel-meta/cfg/scratch/obj/home/rpjday/swe/recipes-kernel/linux/linux-windriver/ssd_sil.cfg
[INFO] Sanitizing .kernel-meta/cfg/kernel-meta/cfg/systemd.cfg

so far, so good.

  now, let's extend SRC_URI to pick up one more item, but this one
from the lower mxeiii/ directory:

SRC_URI += " \
        file://new_board.scc \
        file://uio.scc \
        file://ssd_sil.scc \
        file://mm.scc \              <----- new item
"

after a clean and configure:


ERROR: Function failed: do_kernel_configme (log file is located at
/home/rpjday/Builds/swe/8/m/bitbake_build/tmp/work/mxeiii-wrs-linux/linux-windriver/4.1-r0/temp/do_kernel_configme/log.do_kernel_configme.11821)
ERROR: Logfile of failure stored in:
/home/rpjday/Builds/swe/8/m/bitbake_build/tmp/work/mxeiii-wrs-linux/linux-windriver/4.1-r0/temp/do_kernel_configme/log.do_kernel_configme.11821
Log data follows:
| DEBUG: Executing shell function do_kernel_configme
| NOTE: kernel configme
| [INFO] Configuring target/machine combo: "standard/mxeiii"
| ERROR: could not sanitize configuration fragments
|    errors are logged in
/home/rpjday/Builds/swe/8/m/bitbake_build/tmp/work-shared/mxeiii/kernel-source/.kernel-meta/cfg/standard/mxeiii/config.log
| WARNING:
/home/rpjday/Builds/swe/8/m/bitbake_build/tmp/work/mxeiii-wrs-linux/linux-windriver/4.1-r0/temp/do_kernel_configme/run.do_kernel_configme.11821:1
exit 1 from
|   configme ${configmeflags} --reconfig --output
/home/rpjday/Builds/swe/8/m/bitbake_build/tmp/work/mxeiii-wrs-linux/linux-windriver/4.1-r0/linux-mxeiii-standard-build
standard mxeiii
| ERROR: Function failed: do_kernel_configme (log file is located at
/home/rpjday/Builds/swe/8/m/bitbake_build/tmp/work/mxeiii-wrs-linux/linux-windriver/4.1-r0/temp/do_kernel_configme/log.do_kernel_configme.11821)
ERROR: Task 6
(/home/rpjday/Builds/swe/8/m/layers/wr-kernel/recipes-kernel/linux/linux-windriver_4.1.bb,
do_kernel_configme) failed with exit code '1'

and here's the config.log file from that attempt:

[INFO] Sanitizing .kernel-meta/cfg/mxeiii/new_board.cfg
[INFO] Sanitizing .kernel-meta/cfg/uio.cfg
[ERROR] Kern frag .kernel-meta/cfg/uio.cfg does not exist

Notice how this differs from the first two lines from the successful
configure before:

[INFO] Sanitizing .kernel-meta/cfg/mxeiii/new_board.cfg
[INFO] Sanitizing
.kernel-meta/cfg/scratch/obj/home/rpjday/swe/recipes-kernel/linux/linux-windriver/uio.cfg

The pattern appears to be that, once the SRC_URI search is forced to
enter that mxeiii/ subdirectory to find something, the search for
previously found SRC_URI items gets totally borked.

I've tried this several times, and the behaviour is consistent.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: is there a known issue with how SRC_URI uses OVERRIDES to locate .scc files?

[Robert P. J. Day]

On Wed, 20 Apr 2016, Bruce Ashfield wrote:

> You haven't supplied your SRC_URI in the question ... what does it
> look like ?
>
> It has no relation to the SRC_URI, probably a run of the mill bug in
> the processing code. I'd suggest taking it up with Wind River
> support.
>
> Alternatively, if you have this somewhere that I clone and launch a
> test build, I can help you out .. but I won't be able to easily
> reproduce that situation from scratch.

  ok, i found what appears to be a cheap workaround for this, and i'm
curious if this makes any sense.  recall original kernel recipe
directory structure:

  linux-windriver/
    uio.*
    ssd.*
    mxeiii/
      mm.*

when SRC_URI mentioned only that first-level stuff (uio, ssd), then
the configure step worked fine. but as soon as i added the mm.scc file
to SRC_URI, it just seems that any descent into a lower-level
directory based on OVERRIDES totally bones the search process. so, i
wondered, how can i work around this?

  oh, wait, no problem. see, all target boards are powerpc, so
"powerpc" is one of the possible OVERRIDES. obviously, there is no
*actual* value in using an OVERRIDE for which *every* *single* *board*
is compatible ... oh, wait, there is.

  so i restructured:

  linux-windriver/
    mxeiii/
      mm.*
    powerpc/
      uio.*
      ssd.*

it looks idiotic to take the uio.* and ssd.* content, which should be
generic, and deliberately put it in a subdirectory, unless that
subdirectory represents an OVERRIDE which matches every board and, ta
da, solves the problem.

  i need a drink.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: is there a known issue with how SRC_URI uses OVERRIDES to locate .scc files?

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 2846 bytes --]

On Wed, Apr 20, 2016 at 6:37 PM, Robert P. J. Day <rpjday@crashcourse.ca>
wrote:

> On Wed, 20 Apr 2016, Bruce Ashfield wrote:
>
> > You haven't supplied your SRC_URI in the question ... what does it
> > look like ?
> >
> > It has no relation to the SRC_URI, probably a run of the mill bug in
> > the processing code. I'd suggest taking it up with Wind River
> > support.
> >
> > Alternatively, if you have this somewhere that I clone and launch a
> > test build, I can help you out .. but I won't be able to easily
> > reproduce that situation from scratch.
>
>   ok, i found what appears to be a cheap workaround for this, and i'm
> curious if this makes any sense.  recall original kernel recipe
> directory structure:
>
>   linux-windriver/
>     uio.*
>     ssd.*
>     mxeiii/
>       mm.*
>
> when SRC_URI mentioned only that first-level stuff (uio, ssd), then
> the configure step worked fine. but as soon as i added the mm.scc file
> to SRC_URI, it just seems that any descent into a lower-level
> directory based on OVERRIDES totally bones the search process. so, i
> wondered, how can i work around this?
>
>   oh, wait, no problem. see, all target boards are powerpc, so
> "powerpc" is one of the possible OVERRIDES. obviously, there is no
> *actual* value in using an OVERRIDE for which *every* *single* *board*
> is compatible ... oh, wait, there is.
>
>   so i restructured:
>
>   linux-windriver/
>     mxeiii/
>       mm.*
>     powerpc/
>       uio.*
>       ssd.*
>
> it looks idiotic to take the uio.* and ssd.* content, which should be
> generic, and deliberately put it in a subdirectory, unless that
> subdirectory represents an OVERRIDE which matches every board and, ta
> da, solves the problem.
>
>   i need a drink.


Following up to the list. I was able to take a reproducer for this and
indeed find some *really*
old code that didn't handle a trailing / properly. The end result was the
inability to find the
configuration fragments that were not in subdirectories.

Amazing ability to shoot through corner cases and trigger the problem.

I've made the minor tweak to the processing and will let it soak for a bit
.. but this should
now be solved.

.. now I need a drink.

Bruce


>


> rday
>
> --
>
> ========================================================================
> Robert P. J. Day                                 Ottawa, Ontario, CANADA
>                         http://crashcourse.ca
>
> Twitter:                                       http://twitter.com/rpjday
> LinkedIn:                               http://ca.linkedin.com/in/rpjday
> ========================================================================
>
>
>


-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

[-- Attachment #2: Type: text/html, Size: 4171 bytes --]

Re: is there a known issue with how SRC_URI uses OVERRIDES to locate .scc files?

[Robert P. J. Day]

[-- Attachment #1: Type: text/plain, Size: 2745 bytes --]

On Wed, 20 Apr 2016, Bruce Ashfield wrote:

>
>
> On Wed, Apr 20, 2016 at 6:37 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>       On Wed, 20 Apr 2016, Bruce Ashfield wrote:
>
>       > You haven't supplied your SRC_URI in the question ... what does it
>       > look like ?
>       >
>       > It has no relation to the SRC_URI, probably a run of the mill bug in
>       > the processing code. I'd suggest taking it up with Wind River
>       > support.
>       >
>       > Alternatively, if you have this somewhere that I clone and launch a
>       > test build, I can help you out .. but I won't be able to easily
>       > reproduce that situation from scratch.
>
>         ok, i found what appears to be a cheap workaround for this, and i'm
>       curious if this makes any sense.  recall original kernel recipe
>       directory structure:
>
>         linux-windriver/
>           uio.*
>           ssd.*
>           mxeiii/
>             mm.*
>
>       when SRC_URI mentioned only that first-level stuff (uio, ssd), then
>       the configure step worked fine. but as soon as i added the mm.scc file
>       to SRC_URI, it just seems that any descent into a lower-level
>       directory based on OVERRIDES totally bones the search process. so, i
>       wondered, how can i work around this?
>
>         oh, wait, no problem. see, all target boards are powerpc, so
>       "powerpc" is one of the possible OVERRIDES. obviously, there is no
>       *actual* value in using an OVERRIDE for which *every* *single* *board*
>       is compatible ... oh, wait, there is.
>
>         so i restructured:
>
>         linux-windriver/
>           mxeiii/
>             mm.*
>           powerpc/
>             uio.*
>             ssd.*
>
>       it looks idiotic to take the uio.* and ssd.* content, which should be
>       generic, and deliberately put it in a subdirectory, unless that
>       subdirectory represents an OVERRIDE which matches every board and, ta
>       da, solves the problem.
>
>         i need a drink.
>
>
> Following up to the list. I was able to take a reproducer for this
> and indeed find some *really* old code that didn't handle a trailing
> / properly. The end result was the inability to find the
> configuration fragments that were not in subdirectories.

  just to be clear, there was no problem finding config fragments that
were not in subdirectories until i somehow triggered the bug by
*adding* an item that *was* in a subdirectory, and that's when things
went to hell.

  so the "bug" apparently never manifested itself until i triggered it
by doing something else. does that sound about right?

rday

Re: is there a known issue with how SRC_URI uses OVERRIDES to locate .scc files?

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 3454 bytes --]

On Thu, Apr 21, 2016 at 4:59 AM, Robert P. J. Day <rpjday@crashcourse.ca>
wrote:

> On Wed, 20 Apr 2016, Bruce Ashfield wrote:
>
> >
> >
> > On Wed, Apr 20, 2016 at 6:37 PM, Robert P. J. Day <rpjday@crashcourse.ca>
> wrote:
> >       On Wed, 20 Apr 2016, Bruce Ashfield wrote:
> >
> >       > You haven't supplied your SRC_URI in the question ... what does
> it
> >       > look like ?
> >       >
> >       > It has no relation to the SRC_URI, probably a run of the mill
> bug in
> >       > the processing code. I'd suggest taking it up with Wind River
> >       > support.
> >       >
> >       > Alternatively, if you have this somewhere that I clone and
> launch a
> >       > test build, I can help you out .. but I won't be able to easily
> >       > reproduce that situation from scratch.
> >
> >         ok, i found what appears to be a cheap workaround for this, and
> i'm
> >       curious if this makes any sense.  recall original kernel recipe
> >       directory structure:
> >
> >         linux-windriver/
> >           uio.*
> >           ssd.*
> >           mxeiii/
> >             mm.*
> >
> >       when SRC_URI mentioned only that first-level stuff (uio, ssd), then
> >       the configure step worked fine. but as soon as i added the mm.scc
> file
> >       to SRC_URI, it just seems that any descent into a lower-level
> >       directory based on OVERRIDES totally bones the search process. so,
> i
> >       wondered, how can i work around this?
> >
> >         oh, wait, no problem. see, all target boards are powerpc, so
> >       "powerpc" is one of the possible OVERRIDES. obviously, there is no
> >       *actual* value in using an OVERRIDE for which *every* *single*
> *board*
> >       is compatible ... oh, wait, there is.
> >
> >         so i restructured:
> >
> >         linux-windriver/
> >           mxeiii/
> >             mm.*
> >           powerpc/
> >             uio.*
> >             ssd.*
> >
> >       it looks idiotic to take the uio.* and ssd.* content, which should
> be
> >       generic, and deliberately put it in a subdirectory, unless that
> >       subdirectory represents an OVERRIDE which matches every board and,
> ta
> >       da, solves the problem.
> >
> >         i need a drink.
> >
> >
> > Following up to the list. I was able to take a reproducer for this
> > and indeed find some *really* old code that didn't handle a trailing
> > / properly. The end result was the inability to find the
> > configuration fragments that were not in subdirectories.
>
>   just to be clear, there was no problem finding config fragments that
> were not in subdirectories until i somehow triggered the bug by
> *adding* an item that *was* in a subdirectory, and that's when things
> went to hell.
>
>   so the "bug" apparently never manifested itself until i triggered it
> by doing something else. does that sound about right?
>

Correct. The subdirs were getting a trailing / and hence when the fragments
were
all gathered up (in case the original location is remote), they were being
dumped
into .kernel-meta/cfg/<the absolute path to the fragment>/foo.cfg.

Later on the configuration was looking for them in just <subdir>/foo.cfg ..
and
couldn't find them.

Bloody trailing slashes!

Bruce


>
> rday




-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

[-- Attachment #2: Type: text/html, Size: 4717 bytes --]