thanks!

This reverts b1dc45a which is going to break out-of-tree tar ball builds again.

https://curl.haxx.se/dev/log.cgi?id=20170420004847-7533#prob1

Tricky. Why does it break the out-of-tree build? I've successfully run my own test builds out-of-tree locally... Can you reproduce that error manually and see if you can understand it?

Or how exactly is $< different than $(MANPAGE) there that explains this?

The problem is building from a tarball where there's a prebuilt docs/curl.1 already so the modified (commit 5b4cbcf) approach doesn't properly rebuild curl.1 in the build tree but still refers to the build tree path in the src/Makefile that builds the curl --manual feature...

Or how exactly is $< different than $(MANPAGE) there that explains this?
I think it's because $< points to the prerequisite (that is, the dependency), which is searched via VPATH, while the $(MANPAGE) variable, when used directly in the rule, is not searched by VPATH - it's just replaced with its value.
A simple test:
--
$ cat Makefile
dep1 = dep1
dep2 = dep2
VPATH = dir
target: $(dep1) $(dep2)
@echo $< and $(dep1) and $(dep2)
--
$ mkdir dir
$ touch dir/dep1
$ touch dep2
--
$ make
dir/dep1 and dep1 and dep2

It's only a problem on builds from the tar ball. The issue has to do with rebuilding the curl.1 file. In the tar ball, the time stamps are such that make does not actually rebuild the file, so the only copy is $(top_srcdir)/docs/curl.1. On git checkouts, the file must be rebuilt (because it's not available from the tar ball) so the only copy is in $(top_builddir)/docs/curl.1. $&lt; uses the VPATH to find the right location of the file, whereas $(MANPAGE) hard-codes it. Yes, it's tricky and it took me a while to come up with b1dc45a. I thought I also verified that $< was standard make syntax before checking it in.

Ok, so let's start over. I've revered this change for now since it wasn't the right thing.

w.r.t. standard make syntax, $< is used all over the place in the curl automakefiles.

To clarify, $< is fine in implied rules, silly example:

.c.o:
    $(CC) -c $<

However, in this case it is an explicit rule:

foo.c:
    $(CC) -c $<

In this case, $< is not defined, at least in FreeBSD's and NetBSD's make.

It's used at an explicit rule at least once, too: in the ca-bundle in the root Makefile.am

@0-wiz-0 so it evaluates completely empty then?

ca-bundle: that needs fixing too, then.
$<: yes, it is empty in explicit rules.

The ca-bundle build can easily just use the variable instead, that's easy. The manpage thing however is much more complicated...

https://github.com/curl/curl/blob/master/src/Makefile.am gives me the following for the MANPAGE variable:

MANPAGE=$(top_builddir)/docs/curl.1

This is an absolute path, so VPATH does not play into this. What am I missing?

This is an absolute path, so VPATH does not play into this. What am I missing?

I'm not sure what you're missing but clearly the previously discussed fix was not good enough for out-of-tree builds. Do you have another suggested take on a fix?

If I understand the viariables correctly $(top_build_dir) is where I ran configure from, where there is a different "top" dir (do not know auto-tools well enough), maybe $(top_src_dir).

One hack could be: check is $(top_src_dir) and $(top_builddir) are equal (during ./configure ??) and define $(MANPAGE) to point at $(top_src_dir) when coming from tarball and to $(top_builddir) when it is going to be generated.
In any case, the "old" way (v7.53.1 worked in any case) worked fine, from tarballs, "out-of-tree".

Update: Sorry - had not seen this was closed already. Ignore.

I tested #1438 with both in-tree and out-of-tree builds and it seems to work as planned, and it doesn't use $< for this anymore.

This is now fixed after #1442 and follow-up commit.