[Buildroot] Parallel make messes up post-build in -next

[Buildroot] Parallel make messes up post-build in -next

[Eric Le Bihan]

Hi!

I am currently testing the -next branch and I've encountered the following
problem: the copy of my overlay and the execution of my post-build script is
now performed *after* the generation of my image.

Reverting commit a24877586a566e052897e50e6a0c2f53cfb029f5, which adds support
for top-level parallel make, fixes the issue.

Has anyone else experienced this problem?

Best regards,
ELB

[Buildroot] Parallel make messes up post-build in -next

[Thomas De Schampheleire]

On Thu, Feb 20, 2014 at 10:55 AM, Eric Le Bihan
<eric.le.bihan.dev@free.fr> wrote:
> Hi!
>
> I am currently testing the -next branch and I've encountered the following
> problem: the copy of my overlay and the execution of my post-build script is
> now performed *after* the generation of my image.
>
> Reverting commit a24877586a566e052897e50e6a0c2f53cfb029f5, which adds support
> for top-level parallel make, fixes the issue.
>
> Has anyone else experienced this problem?

I haven't tried it myself yet.
But, the rootfs and post build scripts are done from target-finalize,
and the rules to make the rootfs depend on target-finalize.
This should be fine (but probably is not and we're overlooking something).

However, aside from the above I have another doubt: I don't see any
special handling for the other special targets like
target-purgelocales, target-generatelocales, ... These targets should
be run after all generic targets, and before creating the rootfs. As
far as I can see, they could now run in parallel with the normal
targets, right?

Thanks,
Thomas

[Buildroot] Parallel make messes up post-build in -next

[Fabio Porcedda]

On Thu, Feb 20, 2014 at 10:55 AM, Eric Le Bihan
<eric.le.bihan.dev@free.fr> wrote:
> Hi!
>
> I am currently testing the -next branch and I've encountered the following
> problem: the copy of my overlay and the execution of my post-build script is
> now performed *after* the generation of my image.
>
> Reverting commit a24877586a566e052897e50e6a0c2f53cfb029f5, which adds support
> for top-level parallel make, fixes the issue.
>
> Has anyone else experienced this problem?
>

Can you try this patch?

diff --git a/Makefile b/Makefile
index 20aabd6..de568e3 100644
--- a/Makefile
+++ b/Makefile
@@ -507,6 +507,8 @@ endif
 STRIP_FIND_CMD += -type f \( -perm /111 -o -name '*.so*' \)
 STRIP_FIND_CMD += -not \( $(call findfileclauses,libpthread*.so*
$(call qstrip,$(BR2_STRIP_EXCLUDE_FILES))) \) -print

+$(TARGETS_ROOTFS): target-finalize
+
 target-finalize: $(TARGETS)
        rm -rf $(TARGET_DIR)/usr/include $(TARGET_DIR)/usr/share/aclocal \
                $(TARGET_DIR)/usr/lib/pkgconfig
$(TARGET_DIR)/usr/share/pkgconfig \
@@ -534,8 +536,6 @@ endif
                find $(TARGET_DIR)/lib/modules -type f -name '*.ko' | \
                xargs -r $(KSTRIPCMD); fi

-$(TARGETS_ROOTFS): target-finalize
-
 # See http://sourceware.org/gdb/wiki/FAQ, "GDB does not see any threads
 # besides the one in which crash occurred; or SIGTRAP kills my program when
 # I set a breakpoint"

Regards
-- 
Fabio Porcedda

[Buildroot] Parallel make messes up post-build in -next

[Eric Le Bihan]

Hi!

On Thu, Feb 20, 2014 at 02:42:17PM +0100, Fabio Porcedda wrote:
> On Thu, Feb 20, 2014 at 10:55 AM, Eric Le Bihan
> <eric.le.bihan.dev@free.fr> wrote:
> > Hi!
> >
> > I am currently testing the -next branch and I've encountered the following
> > problem: the copy of my overlay and the execution of my post-build script is
> > now performed *after* the generation of my image.
> >
> > Reverting commit a24877586a566e052897e50e6a0c2f53cfb029f5, which adds support
> > for top-level parallel make, fixes the issue.
> >
> > Has anyone else experienced this problem?
> >
>
> Can you try this patch?
>
> diff --git a/Makefile b/Makefile
> index 20aabd6..de568e3 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -507,6 +507,8 @@ endif
>  STRIP_FIND_CMD += -type f \( -perm /111 -o -name '*.so*' \)
>  STRIP_FIND_CMD += -not \( $(call findfileclauses,libpthread*.so*
> $(call qstrip,$(BR2_STRIP_EXCLUDE_FILES))) \) -print
>
> +$(TARGETS_ROOTFS): target-finalize
> +
>  target-finalize: $(TARGETS)
>         rm -rf $(TARGET_DIR)/usr/include $(TARGET_DIR)/usr/share/aclocal \
>                 $(TARGET_DIR)/usr/lib/pkgconfig
> $(TARGET_DIR)/usr/share/pkgconfig \
> @@ -534,8 +536,6 @@ endif
>                 find $(TARGET_DIR)/lib/modules -type f -name '*.ko' | \
>                 xargs -r $(KSTRIPCMD); fi
>
> -$(TARGETS_ROOTFS): target-finalize
> -
>  # See http://sourceware.org/gdb/wiki/FAQ, "GDB does not see any threads
>  # besides the one in which crash occurred; or SIGTRAP kills my program when
>  # I set a breakpoint"
The patch fixes the issue. Thank you very much!

Best regards,
ELB

[Buildroot] Parallel make messes up post-build in -next

[Thomas De Schampheleire]

Hi Fabio,

On Thu, Feb 20, 2014 at 2:42 PM, Fabio Porcedda
<fabio.porcedda@gmail.com> wrote:
> On Thu, Feb 20, 2014 at 10:55 AM, Eric Le Bihan
> <eric.le.bihan.dev@free.fr> wrote:
>> Hi!
>>
>> I am currently testing the -next branch and I've encountered the following
>> problem: the copy of my overlay and the execution of my post-build script is
>> now performed *after* the generation of my image.
>>
>> Reverting commit a24877586a566e052897e50e6a0c2f53cfb029f5, which adds support
>> for top-level parallel make, fixes the issue.
>>
>> Has anyone else experienced this problem?
>>
>
> Can you try this patch?
>
> diff --git a/Makefile b/Makefile
> index 20aabd6..de568e3 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -507,6 +507,8 @@ endif
>  STRIP_FIND_CMD += -type f \( -perm /111 -o -name '*.so*' \)
>  STRIP_FIND_CMD += -not \( $(call findfileclauses,libpthread*.so*
> $(call qstrip,$(BR2_STRIP_EXCLUDE_FILES))) \) -print
>
> +$(TARGETS_ROOTFS): target-finalize
> +
>  target-finalize: $(TARGETS)
>         rm -rf $(TARGET_DIR)/usr/include $(TARGET_DIR)/usr/share/aclocal \
>                 $(TARGET_DIR)/usr/lib/pkgconfig
> $(TARGET_DIR)/usr/share/pkgconfig \
> @@ -534,8 +536,6 @@ endif
>                 find $(TARGET_DIR)/lib/modules -type f -name '*.ko' | \
>                 xargs -r $(KSTRIPCMD); fi
>
> -$(TARGETS_ROOTFS): target-finalize
> -
>  # See http://sourceware.org/gdb/wiki/FAQ, "GDB does not see any threads
>  # besides the one in which crash occurred; or SIGTRAP kills my program when
>  # I set a breakpoint"
>


Why do you think this would change anything?
As far as I know, the order of the dependency expression does not matter...

[Buildroot] Parallel make messes up post-build in -next

[Thomas De Schampheleire]

Hi,

On Thu, Feb 20, 2014 at 3:00 PM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> Hi Fabio,
>
> On Thu, Feb 20, 2014 at 2:42 PM, Fabio Porcedda
> <fabio.porcedda@gmail.com> wrote:
>> On Thu, Feb 20, 2014 at 10:55 AM, Eric Le Bihan
>> <eric.le.bihan.dev@free.fr> wrote:
>>> Hi!
>>>
>>> I am currently testing the -next branch and I've encountered the following
>>> problem: the copy of my overlay and the execution of my post-build script is
>>> now performed *after* the generation of my image.
>>>
>>> Reverting commit a24877586a566e052897e50e6a0c2f53cfb029f5, which adds support
>>> for top-level parallel make, fixes the issue.
>>>
>>> Has anyone else experienced this problem?
>>>
>>
>> Can you try this patch?
>>
>> diff --git a/Makefile b/Makefile
>> index 20aabd6..de568e3 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -507,6 +507,8 @@ endif
>>  STRIP_FIND_CMD += -type f \( -perm /111 -o -name '*.so*' \)
>>  STRIP_FIND_CMD += -not \( $(call findfileclauses,libpthread*.so*
>> $(call qstrip,$(BR2_STRIP_EXCLUDE_FILES))) \) -print
>>
>> +$(TARGETS_ROOTFS): target-finalize
>> +
>>  target-finalize: $(TARGETS)
>>         rm -rf $(TARGET_DIR)/usr/include $(TARGET_DIR)/usr/share/aclocal \
>>                 $(TARGET_DIR)/usr/lib/pkgconfig
>> $(TARGET_DIR)/usr/share/pkgconfig \
>> @@ -534,8 +536,6 @@ endif
>>                 find $(TARGET_DIR)/lib/modules -type f -name '*.ko' | \
>>                 xargs -r $(KSTRIPCMD); fi
>>
>> -$(TARGETS_ROOTFS): target-finalize
>> -
>>  # See http://sourceware.org/gdb/wiki/FAQ, "GDB does not see any threads
>>  # besides the one in which crash occurred; or SIGTRAP kills my program when
>>  # I set a breakpoint"
>>
>
>
> Why do you think this would change anything?
> As far as I know, the order of the dependency expression does not matter...

I spoke too soon.
There was indeed an actual bug in the original patch, adding a new
rule in between the target-finalize rule. It was not so obvious
because of the many empty lines in target-finalize, though.

Fabio, will you send a patch for this?

Thanks,
Thomas

[Buildroot] Parallel make messes up post-build in -next

[Fabio Porcedda]

On Thu, Feb 20, 2014 at 3:00 PM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> Hi Fabio,
>
> On Thu, Feb 20, 2014 at 2:42 PM, Fabio Porcedda
> <fabio.porcedda@gmail.com> wrote:
>> On Thu, Feb 20, 2014 at 10:55 AM, Eric Le Bihan
>> <eric.le.bihan.dev@free.fr> wrote:
>>> Hi!
>>>
>>> I am currently testing the -next branch and I've encountered the following
>>> problem: the copy of my overlay and the execution of my post-build script is
>>> now performed *after* the generation of my image.
>>>
>>> Reverting commit a24877586a566e052897e50e6a0c2f53cfb029f5, which adds support
>>> for top-level parallel make, fixes the issue.
>>>
>>> Has anyone else experienced this problem?
>>>
>>
>> Can you try this patch?
>>
>> diff --git a/Makefile b/Makefile
>> index 20aabd6..de568e3 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -507,6 +507,8 @@ endif
>>  STRIP_FIND_CMD += -type f \( -perm /111 -o -name '*.so*' \)
>>  STRIP_FIND_CMD += -not \( $(call findfileclauses,libpthread*.so*
>> $(call qstrip,$(BR2_STRIP_EXCLUDE_FILES))) \) -print
>>
>> +$(TARGETS_ROOTFS): target-finalize
>> +
>>  target-finalize: $(TARGETS)
>>         rm -rf $(TARGET_DIR)/usr/include $(TARGET_DIR)/usr/share/aclocal \
>>                 $(TARGET_DIR)/usr/lib/pkgconfig
>> $(TARGET_DIR)/usr/share/pkgconfig \
>> @@ -534,8 +536,6 @@ endif
>>                 find $(TARGET_DIR)/lib/modules -type f -name '*.ko' | \
>>                 xargs -r $(KSTRIPCMD); fi
>>
>> -$(TARGETS_ROOTFS): target-finalize
>> -
>>  # See http://sourceware.org/gdb/wiki/FAQ, "GDB does not see any threads
>>  # besides the one in which crash occurred; or SIGTRAP kills my program when
>>  # I set a breakpoint"
>>
>
>
> Why do you think this would change anything?
> As far as I know, the order of the dependency expression does not matter...

It's my fault for putting the new rule inside another target so i
splitted the previous target...
I was confused by the empty line inside the previous rule, it was my fault.
It is a bug introduced in my latest revision of the patch set :(

Regards
-- 
Fabio Porcedda

[Buildroot] Parallel make messes up post-build in -next

[Fabio Porcedda]

On Thu, Feb 20, 2014 at 3:00 PM, Eric Le Bihan
<eric.le.bihan.dev@free.fr> wrote:
> Hi!
>
> On Thu, Feb 20, 2014 at 02:42:17PM +0100, Fabio Porcedda wrote:
>> On Thu, Feb 20, 2014 at 10:55 AM, Eric Le Bihan
>> <eric.le.bihan.dev@free.fr> wrote:
>> > Hi!
>> >
>> > I am currently testing the -next branch and I've encountered the following
>> > problem: the copy of my overlay and the execution of my post-build script is
>> > now performed *after* the generation of my image.
>> >
>> > Reverting commit a24877586a566e052897e50e6a0c2f53cfb029f5, which adds support
>> > for top-level parallel make, fixes the issue.
>> >
>> > Has anyone else experienced this problem?
>> >
>>
>> Can you try this patch?
>>
>> diff --git a/Makefile b/Makefile
>> index 20aabd6..de568e3 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -507,6 +507,8 @@ endif
>>  STRIP_FIND_CMD += -type f \( -perm /111 -o -name '*.so*' \)
>>  STRIP_FIND_CMD += -not \( $(call findfileclauses,libpthread*.so*
>> $(call qstrip,$(BR2_STRIP_EXCLUDE_FILES))) \) -print
>>
>> +$(TARGETS_ROOTFS): target-finalize
>> +
>>  target-finalize: $(TARGETS)
>>         rm -rf $(TARGET_DIR)/usr/include $(TARGET_DIR)/usr/share/aclocal \
>>                 $(TARGET_DIR)/usr/lib/pkgconfig
>> $(TARGET_DIR)/usr/share/pkgconfig \
>> @@ -534,8 +536,6 @@ endif
>>                 find $(TARGET_DIR)/lib/modules -type f -name '*.ko' | \
>>                 xargs -r $(KSTRIPCMD); fi
>>
>> -$(TARGETS_ROOTFS): target-finalize
>> -
>>  # See http://sourceware.org/gdb/wiki/FAQ, "GDB does not see any threads
>>  # besides the one in which crash occurred; or SIGTRAP kills my program when
>>  # I set a breakpoint"
> The patch fixes the issue. Thank you very much!

That's great, i will send shortly a patch to fix this issue.

Thanks for reporting and testing.

Sorry for the trouble.

Regards
-- 
Fabio Porcedda

[Buildroot] Parallel make messes up post-build in -next

[Fabio Porcedda]

On Thu, Feb 20, 2014 at 2:24 PM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> On Thu, Feb 20, 2014 at 10:55 AM, Eric Le Bihan
> <eric.le.bihan.dev@free.fr> wrote:
>> Hi!
>>
>> I am currently testing the -next branch and I've encountered the following
>> problem: the copy of my overlay and the execution of my post-build script is
>> now performed *after* the generation of my image.
>>
>> Reverting commit a24877586a566e052897e50e6a0c2f53cfb029f5, which adds support
>> for top-level parallel make, fixes the issue.
>>
>> Has anyone else experienced this problem?
>
> I haven't tried it myself yet.
> But, the rootfs and post build scripts are done from target-finalize,
> and the rules to make the rootfs depend on target-finalize.
> This should be fine (but probably is not and we're overlooking something).
>
> However, aside from the above I have another doubt: I don't see any
> special handling for the other special targets like
> target-purgelocales, target-generatelocales, ... These targets should
> be run after all generic targets, and before creating the rootfs. As
> far as I can see, they could now run in parallel with the normal
> targets, right?

Yes, it's a thing to fix for proper parallel bulding support, it's on
my todo list.

The targets target-finalize, target-purgelocales,
target-generatelocales, toolchain-eclipse-register can be executed in
parallel after building the generic targets?

Regards
-- 
Fabio Porcedda

[Buildroot] Parallel make messes up post-build in -next

[Fabio Porcedda]

On Thu, Feb 20, 2014 at 3:03 PM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> Hi,
>
> On Thu, Feb 20, 2014 at 3:00 PM, Thomas De Schampheleire
> <patrickdepinguin@gmail.com> wrote:
>> Hi Fabio,
>>
>> On Thu, Feb 20, 2014 at 2:42 PM, Fabio Porcedda
>> <fabio.porcedda@gmail.com> wrote:
>>> On Thu, Feb 20, 2014 at 10:55 AM, Eric Le Bihan
>>> <eric.le.bihan.dev@free.fr> wrote:
>>>> Hi!
>>>>
>>>> I am currently testing the -next branch and I've encountered the following
>>>> problem: the copy of my overlay and the execution of my post-build script is
>>>> now performed *after* the generation of my image.
>>>>
>>>> Reverting commit a24877586a566e052897e50e6a0c2f53cfb029f5, which adds support
>>>> for top-level parallel make, fixes the issue.
>>>>
>>>> Has anyone else experienced this problem?
>>>>
>>>
>>> Can you try this patch?
>>>
>>> diff --git a/Makefile b/Makefile
>>> index 20aabd6..de568e3 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -507,6 +507,8 @@ endif
>>>  STRIP_FIND_CMD += -type f \( -perm /111 -o -name '*.so*' \)
>>>  STRIP_FIND_CMD += -not \( $(call findfileclauses,libpthread*.so*
>>> $(call qstrip,$(BR2_STRIP_EXCLUDE_FILES))) \) -print
>>>
>>> +$(TARGETS_ROOTFS): target-finalize
>>> +
>>>  target-finalize: $(TARGETS)
>>>         rm -rf $(TARGET_DIR)/usr/include $(TARGET_DIR)/usr/share/aclocal \
>>>                 $(TARGET_DIR)/usr/lib/pkgconfig
>>> $(TARGET_DIR)/usr/share/pkgconfig \
>>> @@ -534,8 +536,6 @@ endif
>>>                 find $(TARGET_DIR)/lib/modules -type f -name '*.ko' | \
>>>                 xargs -r $(KSTRIPCMD); fi
>>>
>>> -$(TARGETS_ROOTFS): target-finalize
>>> -
>>>  # See http://sourceware.org/gdb/wiki/FAQ, "GDB does not see any threads
>>>  # besides the one in which crash occurred; or SIGTRAP kills my program when
>>>  # I set a breakpoint"
>>>
>>
>>
>> Why do you think this would change anything?
>> As far as I know, the order of the dependency expression does not matter...
>
> I spoke too soon.
> There was indeed an actual bug in the original patch, adding a new
> rule in between the target-finalize rule. It was not so obvious
> because of the many empty lines in target-finalize, though.
>
> Fabio, will you send a patch for this?

That's for sure!

Regards
-- 
Fabio Porcedda

[Buildroot] Parallel make messes up post-build in -next

[Arnout Vandecappelle]

On 20/02/14 15:13, Fabio Porcedda wrote:
> On Thu, Feb 20, 2014 at 2:24 PM, Thomas De Schampheleire
> <patrickdepinguin@gmail.com> wrote:
>> On Thu, Feb 20, 2014 at 10:55 AM, Eric Le Bihan
>> <eric.le.bihan.dev@free.fr> wrote:
>>> Hi!
>>>
>>> I am currently testing the -next branch and I've encountered the following
>>> problem: the copy of my overlay and the execution of my post-build script is
>>> now performed *after* the generation of my image.
>>>
>>> Reverting commit a24877586a566e052897e50e6a0c2f53cfb029f5, which adds support
>>> for top-level parallel make, fixes the issue.
>>>
>>> Has anyone else experienced this problem?
>>
>> I haven't tried it myself yet.
>> But, the rootfs and post build scripts are done from target-finalize,
>> and the rules to make the rootfs depend on target-finalize.
>> This should be fine (but probably is not and we're overlooking something).
>>
>> However, aside from the above I have another doubt: I don't see any
>> special handling for the other special targets like
>> target-purgelocales, target-generatelocales, ... These targets should
>> be run after all generic targets, and before creating the rootfs. As
>> far as I can see, they could now run in parallel with the normal
>> targets, right?
> 
> Yes, it's a thing to fix for proper parallel bulding support, it's on
> my todo list.
> 
> The targets target-finalize, target-purgelocales,
> target-generatelocales, toolchain-eclipse-register can be executed in
> parallel after building the generic targets?

 I think target-finalize should depend on all other target-*. It's
something that you may want to call from the command line in order to get
an up-to-date target directory.

 toolchain-eclipse-register can be done in parallel with all the rest, it
should just depend on toolchain. There is nothing really that depends on
it, so probably 'world' is the best choice.


 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Parallel make messes up post-build in -next

[Thomas De Schampheleire]

Hi Fabio,

On Thu, Feb 20, 2014 at 3:13 PM, Fabio Porcedda
<fabio.porcedda@gmail.com> wrote:
[..]
>
> Yes, it's a thing to fix for proper parallel bulding support, it's on
> my todo list.
>
> The targets target-finalize, target-purgelocales,
> target-generatelocales, toolchain-eclipse-register can be executed in
> parallel after building the generic targets?

Since you can select both purgelocales and generatelocales, I would
expect they need to be sequential: first purge then generate (as done
today).
I'd also expect that target-finalize should be finished before
starting the locale stuff, as the post-build script or overlay may add
additional locale stuff that needs to be purged.

Best regards,
Thomas

[Buildroot] Parallel make messes up post-build in -next

[Arnout Vandecappelle]

On 20/02/14 15:28, Thomas De Schampheleire wrote:
> Hi Fabio,
> 
> On Thu, Feb 20, 2014 at 3:13 PM, Fabio Porcedda
> <fabio.porcedda@gmail.com> wrote:
> [..]
>>
>> Yes, it's a thing to fix for proper parallel bulding support, it's on
>> my todo list.
>>
>> The targets target-finalize, target-purgelocales,
>> target-generatelocales, toolchain-eclipse-register can be executed in
>> parallel after building the generic targets?
> 
> Since you can select both purgelocales and generatelocales, I would
> expect they need to be sequential: first purge then generate (as done
> today).

 True.

> I'd also expect that target-finalize should be finished before
> starting the locale stuff, as the post-build script or overlay may add
> additional locale stuff that needs to be purged.

 Hm, I would actually expect the reverse: whatever my post-build script
or overlay does should be final, and not be removed again by
purgelocales. But that is in fact not what happens at the moment.

 Regards,
 Arnout

> 
> Best regards,
> Thomas
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Parallel make messes up post-build in -next

[Thomas De Schampheleire]

On Thu, Feb 20, 2014 at 3:48 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 20/02/14 15:28, Thomas De Schampheleire wrote:
>> Hi Fabio,
>>
>> On Thu, Feb 20, 2014 at 3:13 PM, Fabio Porcedda
>> <fabio.porcedda@gmail.com> wrote:
>> [..]
>>>
>>> Yes, it's a thing to fix for proper parallel bulding support, it's on
>>> my todo list.
>>>
>>> The targets target-finalize, target-purgelocales,
>>> target-generatelocales, toolchain-eclipse-register can be executed in
>>> parallel after building the generic targets?
>>
>> Since you can select both purgelocales and generatelocales, I would
>> expect they need to be sequential: first purge then generate (as done
>> today).
>
>  True.
>
>> I'd also expect that target-finalize should be finished before
>> starting the locale stuff, as the post-build script or overlay may add
>> additional locale stuff that needs to be purged.
>
>  Hm, I would actually expect the reverse: whatever my post-build script
> or overlay does should be final, and not be removed again by
> purgelocales. But that is in fact not what happens at the moment.

I also had the same doubt, but what I wrote is just to mimic the
non-parallel behavior.
The changing of the order of locale stuff and post-build is not
related to the parallel build.

Best regards,
Thomas