|
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
|
|
|
d0e7c454
|
2022-04-18T11:34:07
|
|
Don't install libturbojpeg.pc if WITH_TURBOJPEG=0
Fixes #593
|
|
|
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.
|
|
|
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
|
|
|
a9075a17
|
2019-02-12T13:42:57
|
|
Merge branch 'master' into dev
|
|
|
6a8421fb
|
2019-02-12T13:30:15
|
|
GNUInstallDirs.cmake: Silence CMP0054 warning ...
in CMake 3.11 and later
|
|
|
133e4af0
|
2018-09-04T16:56:22
|
|
Add x32 ABI support on Linux
The x32 ABI is similar to the x86-64 ABI but uses 32-bit pointers.
(Refer to https://sites.google.com/site/x32abi)
Based on:
https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/8da8fc5213d87336d6c7200aaeeca925603e12cf
https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/1e33dfea8042230e266b453f53d69a6e37b7f0de
https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/24ffea78da0f18d0d467d16e02dfb903e6c0181e
https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/dedcf76753c8913ef5c3c6e4ea329d29494b6065
https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/d04228a7b58b9aed5bcbec383630ec1a14a3c9ca
https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/b4ad38316ae1899c8a00b6568bb0325d82edcd7a
Closes #274
|
|
|
4893e5d8
|
2017-11-17T19:00:53
|
|
Merge branch 'master' into dev
|
|
|
f0dd80f2
|
2017-09-20T17:13:46
|
|
Merge branch 'master' into dev
|
|
|
7106ffe5
|
2017-09-02T04:20:03
|
|
Merge branch 'master' into dev
|
|
|
6530203f
|
2016-12-09T10:21:29
|
|
Build: More GNUInstallDirs improvements
These improvements enable build systems to use GNUInstallDirs to define
custom directory variables.
- The set_dir() macro was renamed to GNUInstallDirs_set_install_dir(),
in keeping with the module's established macro naming convention.
- Rather than detecting whether the prefix has changed, the new
GNUInstallDirs_set_install_dir() macro instead examines whether the
default for the variable in question has changed. This allows for
more flexibility, since build systems may decide to change the
defaults based on factors other than the prefix. It also enables the
macro to work properly outside of the module.
- The module now performs directory variable substitution within the
body of GNUInstallDirs_get_absolute_install_dir().
- The JAVADIR variable is no longer included in GNUInstallDirs. That
directory is not part of the GNU spec, and it turns out that various
operating systems use different conventions for the location of Java
classes. Instead, the variable is now implemented in our build
system as a demonstration of the aforementioned GNUInstallDirs
enhancements.
|
|
|
c8358fcb
|
2016-12-08T14:43:59
|
|
Build: Various improvements to install/pkg system
- GNUInstallDirs: any directory variable can now reference any other
directory variable by including its name in angle brackets (<>).
- Changed the documentation of the directory variables in BUILDING.md
accordingly. This commit also includes some formatting tweaks to
that section (using boldface for directory names, as is our
convention.)
- Changed the package scripts such that they use
CMAKE_INSTALL_DATAROOTDIR rather than CMAKE_INSTALL_DATADIR.
- We no longer override the install dir. defaults on Windows unless
performing an official build. It may be useful, for instance, to
use the GNU defaults when installing into an MSYS environment.
|
|
|
d681fa76
|
2016-12-07T10:54:54
|
|
Build: Set install dirs in a more GNU-friendly way
This builds upon the existing GNUInstallDirs module in CMake but adds
the following features to that module:
- The ability to override the defaults for each install directory
through a new set of variables (`CMAKE_INSTALL_DEFAULT_*DIR`).
Before operating system vendors began shipping libjpeg-turbo, it was
meant to be a run-time drop-in replacement for the system's
distribution of libjpeg, so it has traditionally installed itself
under /opt/libjpeg-turbo on Un*x systems by default. On Windows, it
has traditionally installed itself under %SystemDrive%\libjpeg-turbo*,
which is not uncommon behavior for open source libraries (open source
SDKs tend to install outside of the Program Files directory so as to
avoid spaces in the directory name.) At least in the case of Un*x,
the install directory behavior is based somewhat on the Solaris
standard, which requires all non-O/S packages to install their files
under /opt/{package_name}. I adopted that standard for VirtualGL and
TurboVNC while working at Sun, because it allowed those packages to be
located under the same directory on all platforms. I adopted it for
libjpeg-turbo because it ensured that our files would never conflict
with the system's version of libjpeg. Even though many Un*x
distributions ship libjpeg-turbo these days, not all of them ship the
TurboJPEG API library or the Java classes or even the latest version
of the libjpeg API library, so there are still many cases in which it
is desirable to install a separate version of libjpeg-turbo than the
one installed by the system. Furthermore, installing the files under
/opt mimics the directory structure of our official binary packages,
and it makes it very easy to uninstall libjpeg-turbo.
For these reasons, our build system needs to be able to use
non-GNU-compliant defaults for each install directory if
`CMAKE_INSTALL_PREFIX` is set to the default value.
- For each directory variable, the module now detects changes to
`CMAKE_INSTALL_PREFIX` and changes the directory variable accordingly,
if the variable has not been changed by the user.
This makes it easy to switch between our "official" directory
structure and the GNU-compliant directory structure "on the fly"
simply by changing `CMAKE_INSTALL_PREFIX`. Also, this new mechanism
eliminated the need for the crufty mechanism that previously did the
same thing just for the library directory variable.
How it should work:
- If a dir variable is unset, then the module will set an internal
property indicating that the dir variable was initialized to its
default value.
- If the dir variable ever diverges from its default value, then the
internal property is cleared, and it cannot be set again without
unsetting the dir variable.
- If the install prefix changes, and if the internal property
indicates that the dir variable is still set to its default value,
and if the dir variable's value is not being manually changed at the
same time that the install prefix is being changed, then the dir
variable's value is automatically changed to the new default value
for that variable (as determined by the new install prefix.)
- The directory variables are now always cached, regardless of whether
they were set on the command line or not. This ensures that they can
easily be examined and modified after being set, regardless of how they
were set.
This was made possible by the introduction of the aforementioned
`CMAKE_INSTALL_DEFAULT_*DIR` variables.
- Improved directory variable documentation (based on descriptions at
https://www.gnu.org/prep/standards/html_node/Directory-Variables.html)
- The module now allows "<DATAROOTDIR>" to be used as a placeholder in
relative directory variables.
It is replaced "on the fly" with the actual path of
`CMAKE_INSTALL_DATAROOTDIR`.
This should more closely mimic the behavior of the old autotools build
system while retaining our customizations to it, and it should retain
the behavior of the old CMake build system.
Closes #124
|
|
|
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/
|
|
|
3da94de2
|
2016-11-20T19:10:54
|
|
Windows build: Add an "uninstall" target
|
|
|
6aae0077
|
2016-11-15T08:37:04
|
|
CMake build system: Fix the "testclean" target
Regression caused by f9134384b728d8943f252b27464d83c4b7b2d159
This commit also makes the "testclean" target clean up the 4:1:1 test
images. This was implemented in the autotools build system in
1f3635c4969f2319a01c9fe561958815b733227f but was left out of the CMake
build system due to an oversight.
|
|
|
f9134384
|
2016-02-06T14:09:20
|
|
Win: Enable testing cross-compiled builds
When cross-compiling, CMakeLists.txt now generates the CTest script
using relative paths, so that CTest can more easily be executed on a
different machine from the build machine. Furthermore, Windows builds
are now tested using md5cmp, just like on Linux, rather than a CMake
script. This prevents issues with differing CMake locations between
the build and test machines.
This also removes some trailing spaces from the md5cmp code and improves
the readability of the test code in CMakeLists.txt.
|
|
f29ffd3e
|
2013-01-13T03:00:25
|
|
Modify 'make test' so that it uses MD5 sums instead of reference images. This eliminates the need to check most of the test images into the repository, which keeps the source tarball to a reasonable size.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@900 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
5e3bb3e9
|
2012-10-12T10:19:09
|
|
Use a more robust method of obtaining the build timestamp on Windows. 'wmic os get LocalDateTime' will always return the timestamp in the format we want (YYYYMMDD), whereas date /t is sensitive to locale. If wmic fails, then we fall back to using date /t, even though this means that the BUILD variable will end up in the incorrect format on some systems.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.1.x@869 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
75cf4979
|
2012-10-12T10:18:37
|
|
Use a more robust method of obtaining the build timestamp on Windows. 'wmic os get LocalDateTime' will always return the timestamp in the format we want (YYYYMMDD), whereas date /t is sensitive to locale. If wmic fails, then we fall back to using date /t, even though this means that the BUILD variable will end up in the incorrect format on some systems.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.2.x@868 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
a0f878a0
|
2011-04-02T04:43:14
|
|
Add testclean target for cleaning up test images
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@562 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
84697036
|
2010-10-15T03:43:24
|
|
First pass at a CMake build system
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@257 632fc199-4ca6-4c93-a231-07263d6284db
|