should a SRC_URI referring to "rday.cfg" look for "rday.scc"?

should a SRC_URI referring to "rday.cfg" look for "rday.scc"?

[Robert P. J. Day]

  (aside: this is with wind river linux 8 and i dropped bruce a note
about it, but i really should keep this stuff on the mailing list.)

  not sure if this is a WRL issue, or more general OE or YP issue, but
i was doing a kernel config yesterday, and my SRC_URI included, say,
"rday.scc", which incorporated both kernel config fragments and
patches, and that worked fine.

  eventually, after massive refactoring, all that was left of that
item was some kernel configuration which was already in "rday.cfg", so
i edited SRC_URI and replaced "rday.scc" with "rday.cfg", but i left
that old "rday.scc" in that directory (with its referent patches),
assuming it would be ignored.

  did a clean and configure and got:

  | DEBUG: Executing shell function do_kernel_metadata
| ERROR: could not find patch rday.patch, included from
.../rday.scc ...

  it *appears* that, even though SRC_URI now refers to (among other
things) just "rday.cfg", it looks like the configure step is *still*
trying to process "rday.scc", which contains a reference to a now
non-existent patch, hence the failure.

  if i just remove (or rename) "rday.scc", then things work fine. is
this expected behaviour? is there some reason that if SRC_URI
includes, say "derf.cfg", the configuration will automatically look
for and try to process "derf.scc"? or am i just doing something silly?

rday

-- 

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

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

Re: should a SRC_URI referring to "rday.cfg" look for "rday.scc"?

[Bruce Ashfield]

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

On Mon, May 9, 2016 at 6:39 AM, Robert P. J. Day <rpjday@crashcourse.ca>
wrote:

>
>   (aside: this is with wind river linux 8 and i dropped bruce a note
> about it, but i really should keep this stuff on the mailing list.)
>
>   not sure if this is a WRL issue, or more general OE or YP issue, but
> i was doing a kernel config yesterday, and my SRC_URI included, say,
> "rday.scc", which incorporated both kernel config fragments and
> patches, and that worked fine.
>
>   eventually, after massive refactoring, all that was left of that
> item was some kernel configuration which was already in "rday.cfg", so
> i edited SRC_URI and replaced "rday.scc" with "rday.cfg", but i left
> that old "rday.scc" in that directory (with its referent patches),
> assuming it would be ignored.
>
>   did a clean and configure and got:
>
>   | DEBUG: Executing shell function do_kernel_metadata
> | ERROR: could not find patch rday.patch, included from
> .../rday.scc ...
>
>   it *appears* that, even though SRC_URI now refers to (among other
> things) just "rday.cfg", it looks like the configure step is *still*
> trying to process "rday.scc", which contains a reference to a now
> non-existent patch, hence the failure.
>
>   if i just remove (or rename) "rday.scc", then things work fine. is
> this expected behaviour? is there some reason that if SRC_URI
> includes, say "derf.cfg", the configuration will automatically look
> for and try to process "derf.scc"? or am i just doing something silly?
>

There's no automatic inclusions like that. Take a look at your meta-series
and see if
there's an explicit reference to the .scc file.

Otherwise, I'll have to try and reproduce it here.

Bruce


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



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

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

Re: should a SRC_URI referring to "rday.cfg" look for "rday.scc"?

[Robert P. J. Day]

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

On Mon, 9 May 2016, Bruce Ashfield wrote:

>
>
> On Mon, May 9, 2016 at 6:39 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>
>         (aside: this is with wind river linux 8 and i dropped bruce a note
>       about it, but i really should keep this stuff on the mailing list.)
>
>         not sure if this is a WRL issue, or more general OE or YP issue, but
>       i was doing a kernel config yesterday, and my SRC_URI included, say,
>       "rday.scc", which incorporated both kernel config fragments and
>       patches, and that worked fine.
>
>         eventually, after massive refactoring, all that was left of that
>       item was some kernel configuration which was already in "rday.cfg", so
>       i edited SRC_URI and replaced "rday.scc" with "rday.cfg", but i left
>       that old "rday.scc" in that directory (with its referent patches),
>       assuming it would be ignored.
>
>         did a clean and configure and got:
>
>         | DEBUG: Executing shell function do_kernel_metadata
>       | ERROR: could not find patch rday.patch, included from
>       .../rday.scc ...
>
>         it *appears* that, even though SRC_URI now refers to (among other
>       things) just "rday.cfg", it looks like the configure step is *still*
>       trying to process "rday.scc", which contains a reference to a now
>       non-existent patch, hence the failure.
>
>         if i just remove (or rename) "rday.scc", then things work fine. is
>       this expected behaviour? is there some reason that if SRC_URI
>       includes, say "derf.cfg", the configuration will automatically look
>       for and try to process "derf.scc"? or am i just doing something silly?
>
>
> There's no automatic inclusions like that. Take a look at your
> meta-series and see if there's an explicit reference to the .scc
> file.
>
> Otherwise, I'll have to try and reproduce it here.

  i suspect it's some remnant of an older configure that's still
hiding somewhere. i'll try to reproduce it, but i'm guessing if i
totally blew away my project directory and tried again, it would work.

  still, shouldn't doing a "clean" step on the kernel target get rid
of remnants like that?

rday

-- 

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

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

Re: should a SRC_URI referring to "rday.cfg" look for "rday.scc"?

[Robert P. J. Day]

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

On Mon, 9 May 2016, Bruce Ashfield wrote:

> On Mon, May 9, 2016 at 6:39 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>
>         (aside: this is with wind river linux 8 and i dropped bruce a note
>       about it, but i really should keep this stuff on the mailing list.)
>
>         not sure if this is a WRL issue, or more general OE or YP issue, but
>       i was doing a kernel config yesterday, and my SRC_URI included, say,
>       "rday.scc", which incorporated both kernel config fragments and
>       patches, and that worked fine.
>
>         eventually, after massive refactoring, all that was left of that
>       item was some kernel configuration which was already in "rday.cfg", so
>       i edited SRC_URI and replaced "rday.scc" with "rday.cfg", but i left
>       that old "rday.scc" in that directory (with its referent patches),
>       assuming it would be ignored.
>
>         did a clean and configure and got:
>
>         | DEBUG: Executing shell function do_kernel_metadata
>       | ERROR: could not find patch rday.patch, included from
>       .../rday.scc ...
>
>         it *appears* that, even though SRC_URI now refers to (among other
>       things) just "rday.cfg", it looks like the configure step is *still*
>       trying to process "rday.scc", which contains a reference to a now
>       non-existent patch, hence the failure.
>
>         if i just remove (or rename) "rday.scc", then things work fine. is
>       this expected behaviour? is there some reason that if SRC_URI
>       includes, say "derf.cfg", the configuration will automatically look
>       for and try to process "derf.scc"? or am i just doing something silly?
>
>
> There's no automatic inclusions like that. Take a look at your
> meta-series and see if there's an explicit reference to the .scc
> file.
>
> Otherwise, I'll have to try and reproduce it here.

  ah, i just tripped over this again, and here's what's happening. i'm
using overrides to define SRC_URI items in machine-specific
directories, and that works fine, and if i change, say, the .scc or
.cfg files, then do a kernel clean operation and configure again, any
changes i made will be recognized and processed. so far, so good.

  however, i just realized that a related set of SRC_URI files:

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

actually apply to *all* my target boards, so i moved those files up
one directory level to be picked up for all builds.

  the SRC_URI reference to this is unchanged, still contains:

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

but (obviously) the search should *now* find that file in the
general kernel version directory, rather than the board-specific
directory it was in before. not so:

[INFO] Sanitizing .kernel-meta/cfg/mpc8360/kernel_baseline.cfg
[INFO] Sanitizing .kernel-meta/cfg/mpc8360/serial_ucc_uart.cfg
[INFO] Sanitizing .kernel-meta/cfg/uio.cfg
[ERROR] Kern frag .kernel-meta/cfg/uio.cfg does not exist

  it seems that once the configuration process locates the SRC_URI
items the first time, it caches(?) their location, so any *changes*
you make will be picked, but you can't *move* them, even to another
location where they would normally be found based on FILESPATH.

  so ... simple question, what's the command to clear that memory if i
move a SRC_URI item? i did verify that if i *completely* remove the
build directory and start from scratch, then (predictably) it works
fine.

rday

-- 

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

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