On 4/9/24 18:55 Gonzalo Garramuño wrote:

...  Just look for:

find_package(JPEG)

if the system jpeg found is libturbo-jpeg, jpeg8 or jpeg6, it
shouldn't be FLTK's concern.

Agreed.

[...]

- uses the stock libjpeg rather than turbojpeg for simplicity and
consistency with our build

That's difficult also, as, IIRC, libjpeg does not compile natively on
the latest MSVC.

Sure? I'm not aware of any substantial changes in our bundled version of
libjpeg aside from symbol prefixing and maybe a few '#define's or small
mods to suppress compiler warnings. However, my personal builds are
still with VS2019, hence I can't tell if this changed in VS2022.

That said, we're using our own hand-crafted CMakeLists.txt for libjpeg
(as for all bundled libs), this may make a difference.

You need to have a SuperBuild so that all .lib files are installed in
the install location.

The superbuild is not a problem per se, as long as the rest looks
plausible. Thanks for updating the GitHub Issue!

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/c8cdfd79-e636-4c7c-8f6a-5369cc92e6e7%40aljus.de.