]> granicus.if.org Git - libjpeg-turbo/commit
x86[-64] SIMD: Don't auto-generate jsimdcfg.inc
authorDRC <information@libjpeg-turbo.org>
Tue, 10 Apr 2018 20:50:22 +0000 (15:50 -0500)
committerDRC <information@libjpeg-turbo.org>
Tue, 10 Apr 2018 21:46:47 +0000 (16:46 -0500)
commitbfc3ce31576f837398c1077a31e3cb5213551ee2
treeee1bda12d1d368a791a33577f9adb5919cd2d10c
parent269e84c971067f6228be9c720b405efa0fdf3d6c
x86[-64] SIMD: Don't auto-generate jsimdcfg.inc

The old Un*x (autotools-based) build system always auto-generated this
file, but that behavior was more or less a relic of the days before the
libjpeg-turbo colorspace extensions were implemented.  The thinking was
that, if a particular developer wanted to change RGB_RED, RGB_GREEN,
RGB_BLUE, or RGB_PIXELSIZE in order to compress from/decompress to
different RGB pixel layouts, then the SIMD extensions should
automatically respond to those changes whenever they were made to
jmorecfg.h.  The modern reality is that changing RGB_* is no longer
necessary because of the libjpeg-turbo colorspace extensions, and
changing any of the other constants in jsimdcfg.inc can't be done
without making deeper modifications to the SIMD extensions.  In general,
we treat RGB_* as a de facto, immutable part of the legacy libpjeg API.
Realistically, since the values of those constants have been the same in
every Un*x distribution released in the past 20-30 years, any software
that uses a system-supplied build of libjpeg must assume that those
constants will have default values.

Furthermore, even if it made sense to auto-generate jsimdcfg.inc, it was
never possible to do so on Windows, so it was always going to be
necessary to manually generate the Windows version of the file whenever
any of the constants changed.  This commit introduces a new custom CMake
target called "jsimdcfg" that can be used, on Un*x platforms, to
generate jsimdcfg.inc on demand, although this should only be necessary
when introducing new x86 SIMD instructions or making other deep
modifications, such as SIMD acceleration for 12-bit JPEGs.

For those who may be wondering why we don't do the same thing for
win/jconfig.h.in, it's because performing all of the necessary CMake
checks to populate that file is very slow on Windows.
simd/CMakeLists.txt
simd/nasm/jsimdcfg.inc [moved from win/jsimdcfg.inc with 100% similarity, mode: 0644]
simd/nasm/jsimdcfg.inc.h [moved from simd/jsimdcfg.inc.h with 100% similarity]