Make files seem to be incompatible with make 4.3 about rabbitmq-common HOT 16 CLOSED

Here is the line in question. I am trying to reproduce. Some discussed reasons seem to vary.

from rabbitmq-common.

I cannot reproduce using a Sid container started like this:

docker run -i -t debian:sid /bin/bash

the server and all dependencies build successfully and I can confirm that the Make version installed is 4.3. @adeptg what exactly is the Make target used in your case?

from rabbitmq-common.

make dist

also works for me on Sid.

I only could reproduce it late in the run of

make package-deb

from an umbrella clone.

from rabbitmq-common.

I have tried escaping the % and it seems to be a red herring. The real issue is something else. I am out of my Makefile depth here, unfortunately.

from rabbitmq-common.

For what it's worth both make dist and make package-generic-unix work fine via the umbrella on my workstation. Arch Linux, GNU make version 4.3

from rabbitmq-common.

Thanks for checking! If it's not the new make version, it's something else (probably, something in debian/rules).
I'm trying to build it this way:
git clone https://salsa.debian.org/openstack-team/third-party/rabbitmq-server.git
dpkg-buildpackage -uc -us

Will look further into it

from rabbitmq-common.

I suggest starting with the openstack team.

from rabbitmq-common.

@adeptg that's the Debian package I believe (from the core Debian and Ubuntu repositories). Our team has maintained our own for many years.

The package you are trying to build is what you get with standard Debian repositories. What our docs recommend is under rabbitmq/rabbitmq-server-release. The Debian community package is usually months if not years out of date and they have adopted some interesting choices around RabbitMQ in the past. If you absolutely have to produce your own package, I suggest that you consider using our own.

from rabbitmq-common.

@lukebakken note that I could reproduce the failure on Sid so perhaps it can be reopened?

from rabbitmq-common.

Yep, reproduced via debian:sid container and running make package-deb:

make[6]: Entering directory '/root/rabbitmq-public-umbrella/deps/rabbitmq_server_release/packaging/debs/Debian/rabbitmq-server-3.8.0+rc.1.46.g92e0902'
make[6]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
/root/rabbitmq-public-umbrella/deps/rabbitmq_server_release/packaging/debs/Debian/rabbitmq-server-3.8.0+rc.1.46.g92e0902/deps/rabbit_common/mk/rabbitmq-dist.mk:152: *** target pattern contains no '%'.  Stop.
make[6]: Leaving directory '/root/rabbitmq-public-umbrella/deps/rabbitmq_server_release/packaging/debs/Debian/rabbitmq-server-3.8.0+rc.1.46.g92e0902'

from rabbitmq-common.

This seems like something for @dumbbell or @essen to check out since they have GNU make skills.

I set up the container using this script:
debian-sid-setup.sh.txt

from rabbitmq-common.

Hi!

I started to look at this problem. I can reproduce with Debian Sid and the official Debian package of RabbitMQ (3.8.3).

make dist invoked by make install during the build of the Debian package fails with the error reported in this issue. However make dist invoked by make dist earlier during the build works correctly. I can't reproduce outside of the build of the Debian package and I'm using GNU Make 4.3 for quite some time.

I don't know what's going on yet and I'll continue to investigate.

from rabbitmq-common.

It looks like the --no-print-directory flag is ignored/overridden on the following line:

Here is the output diff between the run of make dist when RabbitMQ is built and the same run inside make install called by dh_auto_install(1):

+make[3]: Entering directory '/home/admin/rabbitmq/rabbitmq-server-3.8.3'
+make[3]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
 bin/rabbitmqadmin
+make[3]: Leaving directory '/home/admin/rabbitmq/rabbitmq-server-3.8.3/deps/rabbitmq_management'

The output of that make(1) recipe is eval'd by the calling make(1) and the extra lines cause that eval to fail.

I'm now looking for the reason why the flag is being ignored/overridden.

from rabbitmq-common.

@adeptg: Here is a patch to rabbitmq-dist.mk which works around the problem:

diff --git a/mk/rabbitmq-dist.mk b/mk/rabbitmq-dist.mk
index af1e05a..e5e0706 100644
--- a/mk/rabbitmq-dist.mk
+++ b/mk/rabbitmq-dist.mk
@@ -66,8 +66,8 @@ $$(dist_$(1)_ez): $$(if $$(wildcard $(3)/ebin $(3)/include $(3)/priv),\
 ifeq ($$(shell test -f $(3)/rabbitmq-components.mk \
 	&& grep -q '^list-dist-deps::' $(3)/Makefile && echo yes),yes)
 $$(dist_$(1)_ez): $$(patsubst %,$(3)/%, \
-	$$(shell $(MAKE) --no-print-directory -C $(3) list-dist-deps \
-	APP=$(1) VSN=$(2) EZ_DIR=$$(abspath $$(dist_$(1)_ez_dir))))
+	$$(shell env MAKEFLAGS=--no-print-directory $$(MAKE) -C $(3) list-dist-deps \
+	APP=$(1) VSN=$(2) EZ_DIR=$$(abspath $$(dist_$(1)_ez_dir)) 2>/dev/null))
 endif
 
 ERLANGMK_DIST_APPS += $(1)

Basically, I pass --no-print-directory in a different way to the sub-make. I also drop the sub-make's stderr to ignore the jobserver warning.

It looks like there is an issue with GNU Make 4.3 in the way it passes flags to a sub-make inside $(shell) or in the way that sub-make uses $(MAKEFLAGS). Because our --no-print-directory is ignored and --jobserver doesn't make it either (my guess after seeing the "jobserver unavailable" warning).

What do you think?

Note that the patch is created against RabbitMQ 3.8.3 because I used the official Debian package to reproduce the build failure. I used the following commands to build the package:

dpkg-source -x rabbitmq-server_3.8.3-1.dsc
cd rabbitmq-server-3.8.3
dpkg-buildpackage -uc -us -b -nc -tc

from rabbitmq-common.

Thanks a lot, @dumbbell
I'm not so good with make, unfortunately, but your patch works for me.
I've created a merge request for the debian team with it https://salsa.debian.org/openstack-team/third-party/rabbitmq-server/-/merge_requests/6/diffs
I hope you don't mind :) Please let me know if I'm wrong. Thanks again!

from rabbitmq-common.

That's perfect, thank you!

I didn't report anything to the GNU Make team. It is still unclear to me what's going on. I'm using version 4.3 (on FreeBSD) but didn't see anything wrong with it. On the other hand, debhelper didn't change much w.r.t. make(1)-based builds, so I doubt it is the culprit. If the problem resurfaces at some point, I will dig further.

from rabbitmq-common.