search

kayws426 / embox

Automatically exported from code.google.com/p/embox
0 stars 1 forks source link

Multiple @Rule sources incorrect behaviour on parallel build #648

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Components which use single @Rule to build several sources at once work 
incorrectly during parallel build. Example components are samba and e2fsprogs.
Example from samba:
    @Rule(script="$(MAKE) -C $(THIRDPARTY_DIR)/samba MAKEFLAGS= EMBOX_MAKEFLAGS='$(MAKEFLAGS)' ROOT_DIR=$(abspath $(ROOT_DIR)) EMBOX_CFLAGS='$(CFLAGS)' EMBOX_CXXFLAGS='$(CXXFLAGS)' EMBOX_CPPFLAGS='$(EMBOX_EXPORT_CPPFLAGS)'")
    source
        "../../../../samba/lib/libsmbclient.a",
        "../../../../samba/lib/libtevent.a",
        "../../../../samba/lib/libtalloc.a",
        "../../../../samba/lib/libtdb.a",
        "../../../../samba/lib/libwbclient.a"
When make is invoked with -j<N> flag, mybuild interprets this rule such that it 
attempts to start separate child process for each target, i.e. it runs exactly 
the same command for every "source" file all in parallel. Of course, this is 
not what was intended by script creators (the intention is to create all the 
specified files by single invocation of build script) so the parallel child 
processes conflict with each other which causes different errors depending on 
race conditions.

There might exist different ways to resolve this issue.

Original issue reported on code.google.com by fsul...@gmail.com on 20 Sep 2013 at 1:46

GoogleCodeExporter commented 9 years ago 
@Rule is a rather low-level thing which is directly expressed through Make 
rules. So these limitations are "by-design". It is not intended to run external 
builders. I suggest to use @Build instead.

Original comment by Eldar.Abusalimov on 20 Sep 2013 at 1:55

GoogleCodeExporter commented 9 years ago 
I would suggest a kludgy solution, like generating set of rules which would 
establish sequencing rules for "source" files, like
second: first
third: second
fourth: third
Of course such a rules can be entered into build system manually through 
order.mk for every component under consideration as a workaround.
On the other hand current implementation allows to execute proper files for 
every target in parallel, which might be useful in some cases.
So let's decide which solution do we choose.

Original comment by fsul...@gmail.com on 20 Sep 2013 at 2:25

GoogleCodeExporter commented 9 years ago 
I thought that we could run all @Rule-driven tasks in a sub-make with 
.NOTPARALLEL.
Although, I'm not sure this will work...

Original comment by Eldar.Abusalimov on 20 Sep 2013 at 3:20