On 2016-03-02 10:41 AM, Robert P. J. Day wrote:
Quoting Bruce Ashfield <bruce.ashfi...@windriver.com>:
On 16-03-01 05:44 AM, Robert P. J. Day wrote:
also, once a .scc file is located, will the location of the listed
.cfg and .patch/.diff files inside it start a whole new search process
based on FILESEXTRAPATHS and FILESOVERRIDES?
The search path is created relative to the .scc file that is referencing
a patch, and across any directory that has a .scc file in the SRC_URI.
The .scc feature descriptions are self contained, hence "reaching
outside"
to a parent, or other directory structure isn't a good thing. Just list
things on the SRC_URI if that is required.
one more question, if i might, as i'm still unclear on what flexibility
i have with finding .cfg or .patch files from a .scc file.
imagine i have a number of kernel .bbappend files and corresponding
patch directories:
* linux-4.0.bbappend and linux-4.0/
* linux-4.1.bbappend and linux-4.1/
* linux-4.2.bbappend and linux-4.2/
and so on, as well as wanting to refer to five machines, "m1" through
"m5". consider the following possibility related specifically to
kernel version 4.1:
linux-4.1/
rday.scc
1.patch
2.patch
3.patch
4.patch
m3/
4.patch
so imagine my linux-4.1.bbappend file does SRC_URI += "rday.scc" --
when i do a build for kernel 4.1, the search process should locate
the rday.scc file in linux-4.1/ (as long as i have no other
higher-priority FILESOVERRIDES that get in the way, of course).
now if rday.scc contains references to all four patches and i'm
building for, say, machine "m1", it makes sense that all four
of those patches directly under linux-4.1/ will be the ones
included, correct?
Correct. Assuming rday.scc and the patch files are all within that
directory, it would be:
patch 1.patch
patch 2.patch
... etc.
And that would find the ones local to the .scc file.
but if, instead, i was building for machine "m3", as you can
see, it would be nice if the FILESOVERRIDES feature would kick in
and select the machine-specific patch "m3/4.patch. so all of the
regular patches would be used, *unless* i was building for m3,
at which point the patch m3/4.patch would override the "generic"
4.patch. (the same logic would apply to .cfg files, too, of course.)
is that what would happen? better yet, is that anything i
should even be contemplating? it's not as if i need that feature
right this instant, but it would be nice to know it's available
just in case.
That doesn't happen. Since the searching for patches is not tied
to the fetcher searching and ordering directly.
You can switch on matchines within a .scc file, but that's not
really all that common.
even weirder, could i get away with something like this?
linux-4.1/
rday.scc
1.patch
2.patch
3.patch
4.patch
m3/
rday.scc
4.patch
once again, my .bbappend file would "SRC_URI += rday.scc", and if
i'm building for kernel 4.1, it should find the one directly under
linux-4.1/, *unless* my target machine is "m3", at which point
the file m3/rday.scc would take precedence, which would pick up
the specific patch file m3/4.patch, but would use the higher-level
generic patch files for all others.
Assuming the fetch found m3/rday.scc in the search paths first, it
would be the one selected.
But then the patch references would be relative to m3/, so you wouldn't
even find "patch 1.patch", etc.
The way this is typically configured if you aren't using a kernel-cache
structure is:
linux-<foo>/
machine-type1.scc
machine-type2.scc
machine-type3.scc
common/
1.patch
2.patch
3.patch
4.patch
type3/
4.patch
And then you select the one that matches in your SRC_URI, or if the
.scc files have: "define KMACHINE type1", and you put them ALL on
the SRC_URI, the system will actually pick only the one that
matches the set $MACHINE.
From there, that matching .scc file does all it's own includes of
patches and configuration blocks, etc.
Bruce
the first case i think has value and i'd like to know how to do
it; the second case is admittedly weirder and i'm not sure i
want to defend even *trying* to do it, but i figured i'd ask.
rday
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
