Project organisation for variability of targets

[rhardih]

How to solve the problem of having Dockerfiles for multiple versions of a library?

• What about different architectures?
• What about different variants? E.g. Tesseract with/without support for pango, cairo etc.
• How to go about organizing without bleeding out the entire param interface of ./configure?

[rhardih]

As of f2dff242b9d02de142c3ac8ce986631f90148068, all current rules support versioning. E.g. building version 3.21.0 of sqlite3 can be achieved by postfixing /3.21.0:

make sqlite3/3.21.0

This only introduces support for indicating the version through make, but in no way guarantees compatibility. This opens up another question of how to determine/track valid version combinations of dependent libraries. E.g. leptonica 1.74 works with 4.0.9 of libtiff, but what about other versions of libtiff?

[rhardih]

As of b93896a0e2914e7f439d46720f190fd6e31c5e24, architecture specific rules are now included.

Example:

make sqlite-armv7-a/3.21.0

Default rule syntax omitting arch is still available, defaulting to building the armv7-a version.

[rhardih]

Here's a pickle:

By default e.g. tesseract depends on leptonica, which depends on tiff. That means by default, tesseract will now also depend on tiff being present at runtime, because it will be loaded through leptonica.

In this case, it would be nice, if there was a way to specify a version of leptonica, compiled without tiff as a dependency, as a dependency for tesseract. E.g. a variant of a different name, leptonica-no-tiff.