Sorry, Matteo, I took most of December as vacation from work, and although I
sometimes answered questions and certainly hacked on random things that were of
interest to me, I did semi-intentionally ignore a lot of the usual comms,
especially in the last couple weeks.
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?
I mean, we already don't list /usr/include explicitly in our "Find" modules.
Instead, we rely on cmake to know that for the OS it's running on, that's a
standard system area where headers go, and that the built-in find_blah() cmake
functions will know to look in those areas. So I think if Debian's layout
changes, we ought to be able to assume cmake handles that for us, just like it
did for the old location.
How are all the other projects using cmake handling this?
-- lg
> On Jan 1, 2022, at 3:29 PM, Matteo F. Vescovi <mfvesc...@gmail.com> wrote:
>
> Hi Larry, hi all!
>
> [Let me wear my 'Debian maintainer for OIIO' hat on]
>
> On 2021-12-01 at 09:39 (-08), Larry Gritz wrote:
>> Happy December!
>>
>> We have tagged "v2.3.10.0" as the latest supported production release,
>> and updated the "release" branch marker to that point. This is
>> API/ABI/link back-compatible with prior 2.3 releases.
>
> [...]
>
> Since this release I've issues compiling OIIO in Debian unstable/sid
> due to [1].
>
> The full build log for v2.3.11 with the Cmake error can be
> seen/downloaded at [2]. The relevant snip from it follows:
>
> = = = >8 = = =
> 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:123 (checked_find_package)
> CMakeLists.txt:141 (include)
> = = = >8 = = =
>
> In Debian we're moving to Multi-Arch so include paths are always in the
> form of '/usr/include/<arch>/'; thus I guess the problem here is that
> Cmake module for JPEGTurbo tries to find the header in the wrong place
> (/usr/include/ instead of /usr/include/x86_64-linux-gnu/ in the amd64
> case).
>
> Feel free to ping me for more info and hope we can find a fix for it
> soon.
>
> Cheers... and Happy New Year!
>
> mfv
>
>
> [1]
> https://github.com/OpenImageIO/oiio/commit/32e00ada6a9b858a2ef0f5cdef44fb9427cc8dd0#diff-248add27388e9fd4c946811e2638fc6c01d6e0768aaa48569a8b01be98de50a7
> [2] https://people.debian.org/~mfv/openimageio_2.3.11.0+dfsg-1.buildlog
>
> --
> Matteo F. Vescovi
--
Larry Gritz
l...@larrygritz.com
_______________________________________________
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
