Parallel build terminates with unexpected message when wget and curl are missing

[stweil]

Running make all -j4 on a fresh clone of ocrd_all terminated with these build messages:

configure.ac:382: installing 'config/compile'
configure.ac:86: installing 'config/config.guess'
configure.ac:86: installing 'config/config.sub'
configure.ac:27: installing 'config/install-sh'
configure.ac:27: installing 'config/missing'
Makefile.am: installing 'config/depcomp'
parallel-tests: installing 'config/test-driver'

All done.
To build the software now, do something like:

$ ./configure [--enable-debug] [...other options]

The error was caused because neither curl nor wget was installed. The related error message was hidden somewhere in the middle of the build protocol:

Makefile:641: *** found no cmdline downloader (wget/curl).  Stop.
make: *** Waiting for unfinished jobs....

[bertsky]

And I guess you did not run deps-ubuntu first?

I don't see the issue. This dependency has existed for quite long, and non-Ubuntu users are instructed to install these by hand in the README. And that running with -j can scatter your error messages isn't news either...

[stweil]

Robert, you and I know how to do this right, and usually we are also able to find the reason for problems and fix them.

But I expect more from ocrd_all than support for experts. I think it should also work for users with less experience who also may make errors, and it should help those users to find the root cause of a problem.

That's why I test such scenarios, and here ocrd_all failed to fulfill my expectations.

Even if nobody fixes this issue it makes sense to document it, because then users can at least find it and get hints how to solve it.

[kba]

How about a make check target to detect such problems before running make all? We could document this in the README.md and give precise error and remediation messages?

[stweil]

That could be a solution, and we could even make all depend on that target. Then all preconditions would be checked (which I expect takes less than a second) before starting the large build (and failing somewhere on the way).

I am not sure whether check is not reserved for checking the result of a build, so maybe a different target name would be better, something like pre-checkor check-preconditions.

[bertsky]

But I expect more from ocrd_all than support for experts.

We have documented the dependencies, we have provided an automatic solution for our target platform, and documented everything again in the setup guide.

What you are asking for is an automatic solution for an unsupported platform. Why should we offer that to non-experts?

Even if nobody fixes this issue it makes sense to document it, because then users can at least find it and get hints how to solve it.

I couldn't disagree more. Either this is an issue, then it must be fixed. Otherwise it should be closed to not bloat the space with real open problems. Users must read the actual documentation, not work through bug trackers.

For the problem of supporting other platforms, there's already #56. And for possible configurations on half-supported platforms, we are already discussing #147.

How about a make check target to detect such problems before running make all?

That would reduplicate everything that make deps-ubuntu or make all tries to do. Why bind manual effort to introduce and manage a redundant level of knowledge?

[stweil]

I now think that make check could be used for pre checks and post checks.

Running it before any build would check the preconditions and tell users, that a final check requires make all.
Running it after make all would check the build results.