|
942ac87e
|
2025-06-14T07:45:48
|
|
Build: Allow disabling tests/command-line tools
This is useful for downstream projects that include libjpeg-turbo via
ExternalProject_Add().
Closes #818
|
|
|
4c72bb80
|
2025-05-13T17:00:20
|
|
Build/CI: Officially support Windows/Arm
- Use Visual Studio 2022 for CI builds.
- Rename installers to clearly distinguish x86, x64, and Arm64 versions.
NOTE: The Windows/Arm installer uses the same internal name and install
directory as the Windows/x64 installer. That is consistent with the
behavior of the Linux packages. Because the installer places
turbojpeg.dll into C:\WINDOWS\System32, it would normally be impossible
to co-install the x64 and Arm64 versions anyhow. (That can still be
accomplished. You just have to use 7-Zip to extract one of the
installers into a non-default directory.)
|
|
|
be7a0c8b
|
2024-12-11T12:25:16
|
|
Build: Make Mac packaging architecture-agnostic
Rename the ARMV8_BUILD CMake variable to SECONDARY_BUILD, and modify the
makemacpkg script so that it allows any architecture in a primary or
secondary build. The idea is that Apple Silicon users can package an
arm64 primary build and a secondary x86_64 build, and Intel users can
package an x86_64 primary build and a secondary arm64 build, using the
same procedure.
Also simplify the iOS build instructions, using the
CMAKE_OSX_ARCHITECTURES variable rather than a toolchain.
|
|
|
2351a2d5
|
2024-09-16T12:30:27
|
|
Build: Support LLVM/Windows
Since LLVM/Windows emulates Visual Studio, CMake sets
CMAKE_C_SIMULATE_ID="MSVC" but does not set MSVC. Thus, our build
system needs to enable most (but not all) of the Visual Studio features
when CMAKE_C_SIMLUATE_ID="MSVC". Support for LLVM/Windows is currently
undocumented because it isn't a standalone build environment. (It
requires the Visual Studio and Windows SDK headers and link libraries.)
Closes #786
|
|
|
e8b40f3c
|
2022-11-01T21:45:39
|
|
Vastly improve 12-bit JPEG integration
The Gordian knot that 7fec5074f962b20ed00b4f5da4533e1e8d4ed8ac attempted
to unravel was caused by the fact that there are several
data-precision-dependent (JSAMPLE-dependent) fields and methods in the
exposed libjpeg API structures, and if you change the exposed libjpeg
API structures, then you have to change the whole API. If you change
the whole API, then you have to provide a whole new library to support
the new API, and that makes it difficult to support multiple data
precisions in the same application. (It is not impossible, as example.c
demonstrated, but using data-precision-dependent libjpeg API structures
would have made the cjpeg, djpeg, and jpegtran source code hard to read,
so it made more sense to build, install, and package 12-bit-specific
versions of those applications.)
Unfortunately, the result of that initial integration effort was an
unreadable and unmaintainable mess, which is a problem for a library
that is an ISO/ITU-T reference implementation. Also, as I dug into the
problem of lossless JPEG support, I realized that 16-bit lossless JPEG
images are a thing, and supporting yet another version of the libjpeg
API just for those images is untenable.
In fact, however, the touch points for JSAMPLE in the exposed libjpeg
API structures are minimal:
- The colormap and sample_range_limit fields in jpeg_decompress_struct
- The alloc_sarray() and access_virt_sarray() methods in
jpeg_memory_mgr
- jpeg_write_scanlines() and jpeg_write_raw_data()
- jpeg_read_scanlines() and jpeg_read_raw_data()
- jpeg_skip_scanlines() and jpeg_crop_scanline()
(This is subtle, but both of those functions use JSAMPLE-dependent
opaque structures behind the scenes.)
It is much more readable and maintainable to provide 12-bit-specific
versions of those six top-level API functions and to document that the
aforementioned methods and fields must be type-cast when using 12-bit
samples. Since that eliminates the need to provide a 12-bit-specific
version of the exposed libjpeg API structures, we can:
- Compile only the precision-dependent libjpeg modules (the
coefficient buffer controllers, the colorspace converters, the
DCT/IDCT managers, the main buffer controllers, the preprocessing
and postprocessing controller, the downsampler and upsamplers, the
quantizers, the integer DCT methods, and the IDCT methods) for
multiple data precisions.
- Introduce 12-bit-specific methods into the various internal
structures defined in jpegint.h.
- Create precision-independent data type, macro, method, field, and
function names that are prefixed by an underscore, and use an
internal header to convert those into precision-dependent data
type, macro, method, field, and function names, based on the value
of BITS_IN_JSAMPLE, when compiling the precision-dependent libjpeg
modules.
- Expose precision-dependent jinit*() functions for each of the
precision-dependent libjpeg modules.
- Abstract the precision-dependent libjpeg modules by calling the
appropriate precision-dependent jinit*() function, based on the
value of cinfo->data_precision, from top-level libjpeg API
functions.
|
|
|
664b64a9
|
2022-11-03T14:25:35
|
|
Merge branch 'main' into dev
|
|
|
4f7a8afb
|
2022-11-03T13:37:55
|
|
Build: Fix issues w/ Ninja Multi-Config generator
- Fix an issue whereby a build with ENABLE_SHARED=0 could not be
installed when using the Ninja Multi-Config CMake generator.
- Fix an issue whereby a Windows installer could not be built when using
the Ninja Multi-Config CMake generator.
- Fix an issue whereby the Java regression tests failed when using the
Ninja Multi-Config CMake generator.
Based on:
https://github.com/stilllman/libjpeg-turbo/commit/4f169deeb092a0513472b04f05f57bfe42b31ceb
Closes #626
|
|
|
b98dabac
|
2022-04-27T12:38:58
|
|
Merge branch 'main' into dev
|
|
|
d0e7c454
|
2022-04-18T11:34:07
|
|
Don't install libturbojpeg.pc if WITH_TURBOJPEG=0
Fixes #593
|
|
|
263386c2
|
2022-03-11T17:35:59
|
|
Merge branch 'main' into dev
|
|
|
30cba2a2
|
2022-03-11T11:49:34
|
|
Build/Win: Fix CMake warning when WITH_TURBOJPEG=0
When 12-bit-per-component JPEG support is enabled (WITH_12BIT=1) or the
TurboJPEG API library and associated test programs are disabled
(WITH_TURBOJPEG=0), the Windows installer target should not depend on
the turbojpeg, turbojpeg-static, and tjbench targets.
|
|
|
7fec5074
|
2022-03-08T12:34:11
|
|
Support 8-bit & 12-bit JPEGs using the same build
Partially implements #199
This commit also implements a request from #178 (the ability to compile
the libjpeg example as a standalone program.)
|
|
|
a3d4aadd
|
2022-02-01T12:53:28
|
|
Build: Embed version/API/(C) info in MSVC DLLs
Based on:
https://github.com/TheDorkKnight/libjpeg-turbo/commit/da7a18801a5c305d3f8a71b065f179f1e22b73ae
Closes #576
|
|
|
0081c2de
|
2021-07-07T10:12:46
|
|
Neon/AArch32: Fix build if 'soft' float ABI used
Arm compilers have three floating point ABI options:
'soft' compiles floating point operations as function calls into a
software floating point library, which emulates floating point
operations using integer operations. Floating point function arguments
are passed using integer registers.
'softfp' also compiles floating point operations as function calls into
a floating point library and passes floating point function arguments
using integer registers, but the floating point library functions can
use FPU instructions if the CPU supports them.
'hard' compiles floating point operations into inline FPU instructions,
similarly to x86 and other architectures, and passes floating point
function arguments using FPU registers.
Not all AArch32 CPUs have FPUs or support Neon instructions, so on Linux
and Android platforms, the AArch32 SIMD dispatcher in libjpeg-turbo only
enables the Neon SIMD extensions at run time if /proc/cpuinfo indicates
that the CPU supports Neon instructions or if Neon instructions are
explicitly enabled (e.g. by passing -mfpu=neon to the compiler.) In
order to support all AArch32 CPUs using the same code base, i.e. to
support run-time FPU and Neon auto-detection, it is necessary to compile
the scalar C source code using -mfloat-abi=soft. However, the 'soft'
floating point ABI cannot be used when compiling Neon intrinsics, so the
intrinsics implementation of the Neon SIMD extensions must be compiled
using -mfloat-abi=softfp if the scalar C source code is compiled using
-mfloat-abi=soft.
This commit modifies the build system so that it detects whether
-mfloat-abi=softfp must be explicitly added to the compiler flags when
building the intrinsics implementation of the Neon SIMD extensions.
This will be necessary if the build is using the 'soft' floating
point ABI along with run-time auto-detection of Neon instructions.
Fixes #523
|
|
|
21d05684
|
2020-12-03T18:50:08
|
|
Build: Test for correct AArch32 RPM/DEBARCH value
... based on the floating point ABI being used by the compiler (which
do you choose, a hard or soft option?)
|
|
|
0ba70b6a
|
2020-11-18T15:01:24
|
|
Build: Support macOS Armv8/x86-64 univ. binaries
- Rename IOS_ARMV8_BUILD to ARMV8_BUILD.
- Rename install_ios() to install_subbuild() in makemacpkg.
- Wordsmith the build instructions accordingly.
- Use xcode12.2 image in Travis CI.
|
|
|
f7a10a61
|
2020-11-17T13:51:28
|
|
Build: "OS X"/"OSX" = "macOS"/"MACOS"
There are no supported versions of "OS X" anymore. The operating system
has been named "macOS" since 10.12 Sierra, which was released four years
ago.
|
|
|
59352195
|
2020-10-19T21:17:46
|
|
Merge branch 'master' into dev
|
|
|
f7ca3c5a
|
2020-10-19T15:34:03
|
|
Build: Improve Arm 32-bit cross-comp./packaging
- Set CPU_TYPE=arm if performing a 32-bit build on an AArch64 system.
This eliminates the need to use a CMake toolchain file.
- Set RPMARCH=armv7hl if building on a 32-bit Arm system with an FPU.
- Set RPMARCH=armv7hl and DEBARCH=armhf if performing a 32-bit build
using a gnueabihf toolchain.
- If performing a 32-bit Arm build, generate a 32-bit supplementary DEB
package for AArch64 systems.
|
|
|
1ed312ea
|
2020-10-15T17:47:31
|
|
"ARM"="Arm", "NEON"="Neon"
Refer to:
https://www.arm.com/company/policies/trademarks/arm-trademark-list/arm-trademark
https://www.arm.com/company/policies/trademarks/arm-trademark-list/neon-trademark
NOTE: These changes are only applied to change log entries for 2.0.x and
later, since the change log is a historical record and Arm's new
trademark policy did not go into effect until late 2017.
|
|
|
b8200c66
|
2019-03-08T11:57:54
|
|
Build: Add CMake package config files
Based on:
https://github.com/hjmallon/libjpeg-turbo/commit/d34b89b41134bd2b581e222514ee493594193d87
Closes #339
Closes #342
|
|
|
ae08115d
|
2020-10-15T10:25:46
|
|
Merge branch 'master' into dev
|
|
b5a14727
|
2020-10-15T10:22:51
|
|
Build: Fix permissions
|
|
|
4c5a15c3
|
2020-06-25T19:08:19
|
|
Eliminate 32-bit Mac build/packaging support
The scales have now tilted overwhelmingly in favor of eliminating
support for 32-bit Macs:
- 32-bit applications are only necessary in order to support OS X 10.5
"Leopard" and OS X 10.6 "Snow Leopard". OS X 10.7 "Lion" requires a
64-bit Mac and supports all 64-bit Macs.
- 32-bit applications are no longer allowed in the macOS App Store.
- 32-bit applications no longer run in macOS 10.15 "Catalina".
- 32-bit applications do not support thread-local storage, so the
TurboJPEG API library's global error handler is not thread-safe with
such applications.
- libjpeg-turbo 2.1.x no longer supports 32-bit iOS apps, so it makes
sense to also eliminate support for 32-bit macOS applications.
It's time.
|
|
|
b797f700
|
2020-06-25T19:05:45
|
|
Build: Eliminate Cygwin packaging support
We haven't provided official Cygwin builds since 1.4.x, since Cygwin
now supplies its own libjpeg-turbo packages (although they apparently
haven't been updated past 1.5.3.)
|
|
|
9a2cf323
|
2020-02-11T13:41:43
|
|
Build: Enable separate iOS pkg/DMG w/ sim support
Refer to #406
|
|
|
95f4d6ef
|
2019-10-24T02:13:23
|
|
Merge branch 'master' into dev
|
|
|
708f013f
|
2019-10-22T20:08:57
|
|
Win packaging: Fix 64-bit VC/GCC co-install issue
|
|
|
7fbfe29c
|
2019-07-18T15:18:27
|
|
Merge branch 'master' into dev
|
|
|
ec5adb83
|
2019-05-18T17:58:50
|
|
Build/packaging: Support macOS package/DMG signing
|
|
|
c055c880
|
2019-05-09T20:36:51
|
|
Discontinue support for 32-bit iOS builds
|
|
|
f0dd80f2
|
2017-09-20T17:13:46
|
|
Merge branch 'master' into dev
|
|
|
7106ffe5
|
2017-09-02T04:20:03
|
|
Merge branch 'master' into dev
|
|
|
ff05b6e0
|
2016-12-07T14:09:41
|
|
Build: Fix Win "installer" target Java dependency
The correct target name is now "turbojpeg-java".
|
|
|
e6426d24
|
2016-12-07T10:40:28
|
|
Build: Formatting tweak
(It is our convention to use lowercase for CMake macro/function names)
|
|
|
952191da
|
2016-12-03T14:21:11
|
|
Build: Fix issues when building as a Git submodule
- Replace CMAKE_SOURCE_DIR with CMAKE_CURRENT_SOURCE_DIR
- Replace CMAKE_BINARY_DIR with CMAKE_CURRENT_BINARY_DIR
- Don't use "libjpeg-turbo" in any of the package system filenames
(because CMAKE_PROJECT_NAME will not be the same if building LJT as
a submodule.)
Closes #122
|
|
|
6abd3916
|
2016-11-15T08:47:43
|
|
Unified CMake-based build system
See #56 for discussion.
Fixes #21, Fixes #29, Fixes #37, Closes #56, Fixes #58, Closes #73
Obviates #82
See also:
https://sourceforge.net/p/libjpeg-turbo/feature-requests/5/
https://sourceforge.net/p/libjpeg-turbo/patches/5/
|