Honestly I can't recall anymore. I remember looking into this, as this has been a long-standing annoyance, but I don't recall what the issues were. I'm absolutely in favor of your pursuing this.<br><br><div class="gmail_quote">On Tue Jan 13 2015 at 2:08:08 AM Petter Mabäcker <<a href="mailto:petter@technux.se">petter@technux.se</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 01/12/2015 04:53 PM, Paul Eggleton wrote:<br>
> Hi Petter,<br>
><br>
> On Saturday 10 January 2015 15:40:10 Petter Mabäcker wrote:<br>
>> Currently base.bbclass is creating S if it's not created by unpacking<br>
>> an archive or fetching a repository. If we avoid creating S we can detect<br>
>> when S hasn't been set correctly, since it will not exist. Then we can tell<br>
>> the user that they should set S to a proper value, instead of just failing<br>
>> with odd errors in later tasks.<br>
>><br>
>> Besides removing the auto-creation of S this change will introduce a warning<br>
>> if S is set incorrectly. The reason for not display an error and return is<br>
>> due to all external layers that might have recipes that will fail otherwise<br>
>> and that might be a bit to hard to start with. So use a warning until<br>
>> people have had a chance to cleanup affected recipes.<br>
>><br>
>> [YOCTO #5627]<br>
>><br>
>> Signed-off-by: Petter Mabäcker <<a href="mailto:petter@technux.se" target="_blank">petter@technux.se</a>><br>
>> ---<br>
>> meta/classes/base.bbclass | 17 +++++++++++++----<br>
>> 1 file changed, 13 insertions(+), 4 deletions(-)<br>
>><br>
>> diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass<br>
>> index de50be1..789af3b 100644<br>
>> --- a/meta/classes/base.bbclass<br>
>> +++ b/meta/classes/base.bbclass<br>
>> @@ -113,7 +113,6 @@ python base_do_fetch() {<br>
>><br>
>> addtask unpack after do_fetch<br>
>> do_unpack[dirs] = "${WORKDIR}"<br>
>> -do_unpack[cleandirs] = "${S}/patches"<br>
>> python base_do_unpack() {<br>
>> src_uri = (d.getVar('SRC_URI', True) or "").split()<br>
>> if len(src_uri) == 0:<br>
>> @@ -121,11 +120,21 @@ python base_do_unpack() {<br>
>><br>
>> rootdir = d.getVar('WORKDIR', True)<br>
>><br>
>> + # Ensure that we cleanup ${S}/patches<br>
>> + # TODO: Investigate if we can remove<br>
>> + # the entire ${S} in this case.<br>
>> + s_dir = d.getVar('S', True)<br>
>> + p_dir = os.path.join(s_dir, 'patches')<br>
>> + bb.utils.remove(p_dir, True)<br>
>> +<br>
>> try:<br>
>> fetcher = bb.fetch2.Fetch(src_uri, d)<br>
>> fetcher.unpack(rootdir)<br>
>> except bb.fetch2.BBFetchException as e:<br>
>> raise bb.build.FuncFailed(e)<br>
>> +<br>
>> + if not os.path.exists(s_dir):<br>
>> + bb.warn("%s ('S') don't exist, you must set 'S' to a proper value"<br>
>> % s_dir) }<br>
>><br>
>> def pkgarch_mapping(d):<br>
>> @@ -220,7 +229,7 @@ CONFIGURESTAMPFILE = "${WORKDIR}/configure.sstate"<br>
>> CLEANBROKEN = "0"<br>
>><br>
>> addtask configure after do_patch<br>
>> -do_configure[dirs] = "${S} ${B}"<br>
>> +do_configure[dirs] = "${B}"<br>
>> do_configure[deptask] = "do_populate_sysroot"<br>
>> base_do_configure() {<br>
>> if [ -n "${CONFIGURESTAMPFILE}" -a -e "${CONFIGURESTAMPFILE}" ]; then<br>
>> @@ -238,7 +247,7 @@ base_do_configure() {<br>
>> }<br>
>><br>
>> addtask compile after do_configure<br>
>> -do_compile[dirs] = "${S} ${B}"<br>
>> +do_compile[dirs] = "${B}"<br>
>> base_do_compile() {<br>
>> if [ -e Makefile -o -e makefile -o -e GNUmakefile ]; then<br>
>> oe_runmake || die "make failed"<br>
>> @@ -248,7 +257,7 @@ base_do_compile() {<br>
>> }<br>
>><br>
>> addtask install after do_compile<br>
>> -do_install[dirs] = "${D} ${S} ${B}"<br>
>> +do_install[dirs] = "${D} ${B}"<br>
>> # Remove and re-create ${D} so that is it guaranteed to be empty<br>
>> do_install[cleandirs] = "${D}"<br>
> This looks reasonable to me; however I'm sure I recall Chris talking about<br>
> some kind of complication with this issue a year or so ago - Chris do you<br>
> remember what that was about?<br>
><br>
> Cheers,<br>
> Paul<br>
><br>
Ok, I will wait and see if Chris remembers anything sneaky about this. I<br>
have run quite some tests without seeing any problems so far. Perhaps it<br>
was about removing ${S} instead of just ${S}/patches in do_unpack ?<br>
Because I think there have been some discussions about that in the past.<br>
I also did some test with that in the scope of 'bug 5627', but it is far<br>
more complex to do such a chance, a lot of recipes didn't liked that at<br>
all =/ It seems more correct to really wipe entire ${S} in that case,<br>
but I guess it have to wait..<br>
<br>
BR,<br>
Petter<br>
</blockquote></div>