Re: Possible dependency issue in makefile

Filip Janus <fjanus(at)redhat(dot)com> writes:
> I am building libecpg 13.1 but 13.3 behaves in the same manner and my build
> fails with:
> ...
> Complete build log: log <https://fjanus.fedorapeople.org/postgresql/build.log>

It looks like you're just running configure and then trying to do this:

/usr/bin/make -O -j40 V=1 VERBOSE=1 -C src/interfaces/ecpg

which is probably not a great idea. It bypasses the .NOTPARALLEL:
in src/Makefile, which would normally ensure that src/port gets
built before src/interfaces. If you want to not build the entire
system, I think a minimal approach would be to make src/port,
src/common, src/interfaces/libpq, then src/interfaces/ecpg, in series.

As-is, it looks like two different sub-makes are recursing to build
pg_config_paths.h concurrently. Since the rule for that is

pg_config_paths.h: $(top_builddir)/src/Makefile.global
echo "#define PGBINDIR \"$(bindir)\"" >$@
echo "#define PGSHAREDIR \"$(datadir)\"" >>$@
...
echo "#define HTMLDIR \"$(htmldir)\"" >>$@
echo "#define MANDIR \"$(mandir)\"" >>$@

it's not too surprising that concurrent builds misbehave. I don't
know of any way to prevent make from doing that other than
sprinkling .NOTPARALLEL around a lot more, which would defeat
your purpose in using -j in the first place.

We could possibly adjust this specific rule to create pg_config_paths.h
atomically (say, write to a temp file and then "mv" it into place), but
I don't have any faith that there's not other similar issues behind
this one. Building ecpg by itself is not a case that we test or consider
supported.

regards, tom lane