New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

configure fails when Perl is missing #1565

Closed
webmaster128 opened this Issue Jun 12, 2017 · 13 comments

Comments

Projects
None yet
2 participants
@webmaster128
Contributor

webmaster128 commented Jun 12, 2017

On a system without Perl (e.g. FreeBSD), compilation fails because of checking for perl... no and Built-in manual: enabled for a plain ./configure; make using curl 7.54.0 from zip download.

Full build log.

One other thing I find strange is that after the error output, the command hangs forever instead of failing with non-0 return code.

@bagder

This comment has been minimized.

Member

bagder commented Jun 12, 2017

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

@webmaster128

This comment has been minimized.

Contributor

webmaster128 commented Jun 12, 2017

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

@bagder

This comment has been minimized.

Member

bagder commented Jun 12, 2017

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

@webmaster128

This comment has been minimized.

Contributor

webmaster128 commented Jun 12, 2017

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?

@bagder

This comment has been minimized.

Member

bagder commented Jun 12, 2017

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.

@webmaster128

This comment has been minimized.

Contributor

webmaster128 commented Jun 12, 2017

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
@bagder

This comment has been minimized.

Member

bagder commented Jun 12, 2017

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...

@webmaster128

This comment has been minimized.

Contributor

webmaster128 commented Jun 12, 2017

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.

@bagder

This comment has been minimized.

Member

bagder commented Jun 12, 2017

$(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...

@webmaster128

This comment has been minimized.

Contributor

webmaster128 commented Jun 13, 2017

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.

bagder added a commit that referenced this issue Jun 13, 2017

dist: make the hugehelp.c not get regenerated unnecessarily
The maketgz script now makes sure the generated hugehelp.c file in the
tarball is newer than the generated curl.1 man page, so that it doesn't
have to get unnecessarily rebuilt first thing in a typical build. It
thus also removes the need for perl to build off a plain release
tarball.

Fixes #1565
@webmaster128

This comment has been minimized.

Contributor

webmaster128 commented Jun 13, 2017

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.

@webmaster128

This comment has been minimized.

Contributor

webmaster128 commented Jun 13, 2017

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.

@webmaster128

This comment has been minimized.

Contributor

webmaster128 commented Jun 13, 2017

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

bagder added a commit that referenced this issue Jun 14, 2017

dist: make the hugehelp.c not get regenerated unnecessarily
The maketgz script now makes sure the generated hugehelp.c file in the
tarball is newer than the generated curl.1 man page, so that it doesn't
have to get unnecessarily rebuilt first thing in a typical build. It
thus also removes the need for perl to build off a plain release
tarball.

Fixes #1565

rmarquis added a commit to etlegacy/etlegacy-libs that referenced this issue Jul 1, 2017

@lock lock bot locked as resolved and limited conversation to collaborators May 6, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.