Parallel building of uni*/ dirs

[Bruno Haible]

when building with 'make -jN', the gnulib subidrs uni*/ are built like
with -j1.

Maybe your Makefile contains the line
GNUMAKEFLAGS = -j1
in order to intentionally turn off parallel make?

Or maybe your machine is so loaded that 'make' refrains from using multiple
parallel processes?

Just guessing... (I don't see anything in gnulib or libunistring that would
inhibit parallel make.)

Bruno

[Tim Rühsen]

Post by Bruno Haible

when building with 'make -jN', the gnulib subidrs uni*/ are built like
with -j1.

Maybe your Makefile contains the line
GNUMAKEFLAGS = -j1
in order to intentionally turn off parallel make?
Or maybe your machine is so loaded that 'make' refrains from using multiple
parallel processes?
Just guessing... (I don't see anything in gnulib or libunistring that would
inhibit parallel make.)

GNUMAKEFLAGS isn't set here, files in libunistring/lib are built in
parallel (-j16) while files in libunistring/uni*/ are built on just one
core.

What do you mean with 'is so loaded' ?

Regards, Tim

[Bruno Haible]

Tim,

Post by Tim Rühsen
What do you mean with 'is so loaded' ?

I mean that "top" shows a high load.

'make' looks at these numbers. It has also a '-l' option.

$ nm --dynamic /usr/bin/make | grep load
00000000006320f8 D default_load_average
U getloadavg
0000000000425c10 T hash_load
0000000000415f10 T load_file
0000000000632100 D max_load_average
0000000000416470 T unload_file


Bruno

[Tim Rühsen]

After looking closer, I must amend my first statement.
It seems not to be the subdirs, but the first gcc commands after 'make
clean && make':

Here I have only 1 core utilization:
gcc -DHAVE_CONFIG_H -DNO_XMALLOC -I. -I..  -I. -I. -I.. -I..
-DIN_LIBUNISTRING -DDEPENDS_ON_LIBICONV=1   -g -c amemxfrm.c
gcc -DHAVE_CONFIG_H -DNO_XMALLOC -I. -I..  -I. -I. -I.. -I..
-DIN_LIBUNISTRING -DDEPENDS_ON_LIBICONV=1   -g -c c-ctype.c
gcc -DHAVE_CONFIG_H -DNO_XMALLOC -I. -I..  -I. -I. -I.. -I..
-DIN_LIBUNISTRING -DDEPENDS_ON_LIBICONV=1   -g -c c-strcasecmp.c
...
gcc -DHAVE_CONFIG_H -DNO_XMALLOC -I. -I..  -I. -I. -I.. -I..
-DIN_LIBUNISTRING -DDEPENDS_ON_LIBICONV=1   -g -c version.c
gcc -DHAVE_CONFIG_H -DNO_XMALLOC -I. -I..  -I. -I. -I.. -I..
-DIN_LIBUNISTRING -DDEPENDS_ON_LIBICONV=1   -g -c fseterr.c
gcc -DHAVE_CONFIG_H -DNO_XMALLOC -I. -I..  -I. -I. -I.. -I..
-DIN_LIBUNISTRING -DDEPENDS_ON_LIBICONV=1   -g -c mbrtowc.c

It seems to be a simple for loop (for f in amemxfrm.c c-ctype.h ...).

After this we have a parallel build:
/usr/bin/make  all-am
make[3]: Entering directory '/home/oms/src/libunistring/lib'
/bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H
-DNO_XMALLOC -I. -I..  -I. -I. -I.. -I.. -DIN_LIBUNISTRING
-DDEPENDS_ON_LIBICONV=1   -g -c -o amemxfrm.lo amemxfrm.c
...


I am not an expert here, but using a shell with job control couldn't the
the loop be parallelized  (e.g. when using bash -> parallel run ) ?

Regards, Tim

[Bruno Haible]

Post by Tim Rühsen
I am not an expert here

Neither am I. This would better be a topic for the help-make or bug-make mailing
list, I guess.

Bruno

[Tim Rühsen]

Post by Bruno Haible

Post by Tim Rühsen
I am not an expert here

Neither am I. This would better be a topic for the help-make or bug-make mailing
list, I guess.

Bruno,

why do you think this is a make issue ?

This loop is in gnulib code, lib/Makefile.am (L263, ff. here).

Regards, Tim

[Bruno Haible]

Hi Tim,

Post by Tim Rühsen
This loop is in gnulib code, lib/Makefile.am (L263, ff. here).

I don't see such loops in a typical Makefile.am generated by gnulib-tool.

Can you attach the Makefile.am and Makefile.in, please?

Bruno