Am 09.10.2016 um 11:57 schrieb LanuHum:

> To build the project in Linux, I wrote a single file CMakeLists.txt
...

> set( SOURCE_ROOT                    source )
> set( SOURCE_BASKEND                 source/backend )
> set( SOURCE_BASKEND_BOUNDING        source/backend/bounding )
> set( SOURCE_BASKEND_CONTROL         source/backend/control )
> set( SOURCE_BASKEND_LIGHTING        source/backend/lighting )
> set( SOURCE_BASKEND_RENDER          source/backend/render )
> set( SOURCE_BASKEND_SCENE           source/backend/scene )
> set( SOURCE_BASKEND_SUPPORT         source/backend/support )
...
Isn't that overly verbose? Can't CMake build the contents of an entire
directory tree recursively?

(I guess for your own project you're probably ok with this for now, but
I'm also interested in exploring the potential of CMake for official
POV-Ray, so since you're toying around with CMake anyway, I'd be
grateful if you could investigate a bit further in that direction.)


> fatal error: jversion.h: No such file or directory
>          #include <jversion.h>
...
> Povray does not use an external library libjpeg????
> jpeg-devel package has only these files:
>    /usr/include/jconfig.h
>    /usr/include/jerror.h
>    /usr/include/jmorecfg.h
>    /usr/include/jpegint.h
>    /usr/include/jpeglib.h
>    /usr/include/turbojpeg.h
>    /usr/lib64/libjpeg.so
>    /usr/lib64/libturbojpeg.so

Historically, POV-Ray has been using the contents of `jversion.h` to
determine the version of libjpeg it reports to the end user in the list
of library copyright notices.

This works fine with the Windows version, since it is linked to the
version of libjpeg we're distributing in source code format along with
the POV-Ray for Windows source code; but as you have noticed correctly,
the file is typically unavailable for Unix builds as our Unix build
process nowadays always relies on an external libjpeg (disabling JPEG if
such an external library is unavailable).

In our automake-based Unix build process, this has been worked around by
faking the file, with information obtained by the automake tools via
other means.


I had never investigated this before, but now that I've looked at it I
consider it a bug, or at least a flaw that should (and can) be fixed. I
suspect it might be some artifact from the history of libjpeg. After
all, POV-Ray is in some sense 5 years older than libjpeg, and there may
have been times when `jversion.h` used to be the only file from which
version information could be obtained.

All versions of libjpeg that POV-Ray is still compatible with appear to
provide version information in `jpeglib.h`, and I've just made sure
that's the source future versions of POV-Ray will get their version
information from.

Post a reply to this message