Gutenprint install hooks run in parallel but depend on each other. This
is a race condition and might trigger a build failure (e.g on AB [0]):
| chmod 700 $WORKDIR/image/usr/libexec/cups/backend/backend_gutenprint
| chmod: cannot access '$WORKDIR/image/usr/libexec/cups/backend/backend_gutenprint': Not a directory
| make[5]: *** [Makefile:2166: install-exec-hook] Error 1
Fixes this by adding an explicit dependency between the dependent
targets.
[0]: https://autobuilder.yoctoproject.org/valkyrie/#/builders/87/builds/46/steps/33/logs/stdio
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
This recipe currently uses DIRFILES to work around the fact that both
cups and gutenprint ship /etc/cups but with different ownership.
Instead of having mismatching ownership, we can simply match the
ownership in gutenprint.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
There hasn't been a gutenprint upgrade for quite a while, but a lot of
fixes upstream, so grab the latest SHA.
This means we can now do out-of-tree builds, so drop the use of
autotools-brokensep. Also stop autogen.sh from running configure as we
run it again.
Clean up build dependencies.
Enable NLS, as there's no reason to disable it.
Remove the explicit gutenprint-native recipe, instead use class extension
and build as little as possible in the native do_compile.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
According to wiki more than 1300 printer drivers.
Specifically the CUPS dye-sublimation backend, used in industrial and
medical is a nice fit when using Yocto for embedded solutions targeting
this segment.
As the gutenprint code generate a tool for string management, the native
recipe is designed to just create the output from this tool (a header
file). So the cross compatible version is depending on native version.
Thought about using BBCLASSEXTEND instead of separate files. Though as
the purpose of the two recipes is different (one for generating header
file, the other for generating the actual lib) and different
dependencies I decided to keep it as two recipes.
Signed-off-by: Claus Stovgaard <clst@ambu.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
