That was fixed in #1432, please try a daily snapshot

The return code is fixed, yes. But the main issue (build fail without Perl) remains in curl-7.54.1-20170612

Hm, so that means the makefile somehow deems the file should get regenerated even though it is fresh in the archive...

Isn't the bug already in the ./configure step? Having checking for perl... no and Built-in manual: enabled at the same time in the configure log is a contradiction, isn't it?

No, the tarball comes with the hugehelp.c file pre-built bundled already which is the built-in manual. A build doesn't need perl for that unless it needs to rebuild it.

Okay. It looks like tool_hugehelp.c is older that its dependency curl.1

$ cd curl-7.54.1-20170612
$ ls -lA src/tool_hugehelp.c docs/curl.1 docs/MANUAL src/mkhelp.pl
-rw-r--r-- 1 me me 119418 Jun 12 02:34 docs/curl.1
-rw-r--r-- 1 me me  40069 Mai 31 02:30 docs/MANUAL
-rw-r--r-- 1 me me   6344 Mai 18 02:30 src/mkhelp.pl
-rw-r--r-- 1 me me 558068 Jun 12 02:33 src/tool_hugehelp.c

oh yes, because we've added a "man page date update" script recently that now updates the man pages at the time of the tarball creation ... so we should probably forcibly make the src/tool_hugehelp.c file newer...

Are you talking about updatemanpages.pl? This touches .1 and .3 files in "docs/", "docs/libcurl/", "docs/libcurl/opts/", "tests/". curl.1 is generated from .d files in docs/cmdline-opts:

$(MANPAGE): $(DPAGES) $(OTHERPAGES) Makefile.inc
	/usr/bin/perl $(srcdir)/gen.pl mainpage $(srcdir) > $(MANPAGE)

But isn't this rule insufficient?

$(MANPAGE):
	cd $(top_builddir)/docs && $(MAKE)

if HAVE_LIBZ
# This generates the tool_hugehelp.c file in both uncompressed and
# compressed formats.
$(HUGE): $(MANPAGE) $(README) $(MKHELP)
	echo '#include "tool_setup.h"' > $(HUGE)
	echo '#ifndef HAVE_LIBZ' >> $(HUGE)
[...]

This takes any MANPAGE (=$(abs_top_builddir)/docs/curl.1) for building tool_hugehelp.c even if it is very old and then curl.1 is upated later in the make dist step.

$(HUGE) is rebuilt if any of the $(MANPAGE) $(README) $(MKHELP) files are newer, and as we just concluded, the $(MANPAGE) is bound to always be newer due to how the tarball is made, and thus that file is then attempted to get rebuilt. Which fails if perl is missing and is generally unnecessary since the tarball ships a freshly generated version...

Sorry, I missed some meta: my last comment was about how the tarball is created and how it can be possible that $(HUGE) is older than $(MANPAGE) in the tarball.

From what I could find in the sources, this is not about the updatemanpages.pl step in ./maketgz but about make dist and the insufficient dependency as shown above.

Even if the workaround in #1568 fixes the consequences, the underlying dependency issue remains.

It can be reproduced by running

$ git clean -xdf
$ ./buildconf && ./configure && make
$ ./src/curl -M | tail -n 2                
  Please direct curl questions, feature requests and trouble reports to one of
  these mailing lists instead of mailing any individual.
$ echo XXX >> docs/cmdline-opts/page-footer
$ make
$ ./src/curl -M | tail -n 2
  Please direct curl questions, feature requests and trouble reports to one of
  these mailing lists instead of mailing any individual.

While curl.1 is properly updated when running make after changing page-footer, src/tool_hugehelp.c is not updated.

As far as my research goes, we have a recursive dependency in the build system (tool_hugehelp.c -> curl.1 -> *.d,page-header,page-footer) that automake can only resolve when modelled as subdirectories. I tried to patch this but could not express the dependency: file src/tool_hugehelp.c depends on the docs/ folder to be up-to-date.

Sorry, the example was wrong, since curl -M does not end with page-footer but with MANUAL. Cannot reproduce any more right now. tool_hugehelp.c is rebuild when page-footer was changed (even if I don't see why)

Edit: Okay, the dependency resolution works because SUBDIRS = lib docs src include is executed in that order, causing docs to be up-to-date when src is built.

wow, this is complex. But makes all sense now. #1568 will resolve this.