search

OCR-D / ocrd_all

Master repository which includes most other OCR-D repositories as submodules
MIT License
72 stars 17 forks source link

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

Open stweil opened 4 years ago

stweil commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.