On Tue, Jan 4, 2022 at 3:57 PM Matteo F. Vescovi <mfvesc...@gmail.com>
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 \
>
This has been an interesting conversation. Both Fedora and Debian have been
multi-arch for ages, Fedora with /usr/lib{,64} and Debian with the
/usr/lib/{arch-tuple}. So what is the imperative for /usr/include to be
arch dependent? Should headers be arch agnostic?
Thanks,
Richard
_______________________________________________
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
