CMake: also find jconfig.h from libturbojpeg from arch-specific include directory

[illwieckz]

trafficstars

Description

This header file is architecture-dependent and can be stored as:

• /usr/include/i386-linux-gnu/jconfig.h
• /usr/include/x86_64-linux-gnu/jconfig.h

Instead of:

• /usr/include/jconfig.h

That fixes build errors like this:

CMake Error at src/cmake/modules/FindJPEGTurbo.cmake:32 (file):
  file STRINGS file "/usr/include/jconfig.h" cannot be read.
Call Stack (most recent call first):
  src/cmake/checked_find_package.cmake:127 (find_package)
  src/cmake/externalpackages.cmake:139 (checked_find_package)
  CMakeLists.txt:155 (include)

Checklist:

• [x] I have read the contribution guidelines.
• [x] ~~If this is more extensive than a small change to existing code, I have previously submitted a Contributor License Agreement (individual, and if there is any way my employers might think my programming belongs to them, then also corporate).~~
  This change is too small and not original enough to be subject to copyright.
• [x] ~~I have updated the documentation, if applicable.~~
  Not applicable.
• [x] ~~I have ensured that the change is tested somewhere in the testsuite (adding new test cases if necessary).~~
  Not applicable.
• [x] My code follows the prevailing code style of this project.

[domin144]

Starting with version 2.1.0 libjpeg-turbo provides it's own cmake config files, but they are named different to what is used in oiio cmake files. I think the line:

checked_find_package (JPEGTurbo

Should be changed to:

checked_find_package (libjpeg-turbo

so that distro provided library is detected if present.

[lgritz]

That's interesting, @domin144. I'm tempted to advise abandoning this PR entirely and instead simply removing FindJPEGTurbo.cmake entirely, relying on jpeg-turbo's exported config, and calling it a day. That will mean that we are raising the floor of JPEG-turbo that we support to 2.1. But since that's still 2.5 years old and this is not a required dependency (we can automatically fall back to libjpeg), I think that would be acceptable.

Opinions?

[lgritz]

I tried the other strategy here: https://github.com/OpenImageIO/oiio/pull/3987

What do people think of that proposal, which would obviate the need for this one here?