Awesome, that'll do it! Though I wonder why this would be specific to JPEG.
Maybe better is to ensure that the *general* list of directories it searches for include files (for any project) includes the architecture-specific directories? I'm not sure which CMake variable is the right one to tweak. But it definitely feels like fixing only for JPEG is likely to just bring us back to the same spot eventually for a different dependency. > On Jan 4, 2022, at 1:57 PM, Matteo F. Vescovi <[email protected]> wrote: > > Hi! > > On 2022-01-01 at 18:23 (-08), Larry Gritz wrote: > > [...] > >> It feels like if Debian is generally changing the standard for which >> paths things are installed into, then the best solution is actually a >> fix to cmake itself, to detect if it's on one of these debian systems >> and add the right paths to its standard lists of directories to search >> for things. No? > > Yes. Fixed as follows: > > diff --git a/debian/rules b/debian/rules > index 8cad207..97dd831 100755 > --- a/debian/rules > +++ b/debian/rules > @@ -22,6 +22,7 @@ override_dh_auto_configure: > -DROBINMAP_INCLUDE_DIR="/usr/include/" \ > -DCMAKE_SKIP_RPATH=ON \ > -DINSTALL_FONTS=OFF \ > + -DJPEG_INCLUDE_DIR="/usr/include/$(DEB_HOST_MULTIARCH)" \ > -DOIIO_DOWNLOAD_MISSING_TESTDATA=OFF \ > -DPYTHON_VERSION=$(PY3VERS) \ > -DSTOP_ON_WARNING=OFF \ > > Cheers. > > > -- > Matteo F. Vescovi -- Larry Gritz [email protected]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
