|
2f26b48f
|
2025-04-02T13:59:17
|
|
Mac pkg: Fix issues that prevent notarization
- Explicitly sign all binaries included in the package.
- Enable the hardened runtime.
|
|
|
cc095fee
|
2024-12-18T09:39:53
|
|
Build: Generate 32-bit supplementary ppc64 .deb
As with x86-64, the Power ISA basically implements 64-bit instructions
as extensions of their 32-bit counterparts. Thus, 64-bit Power ISA CPUs
can natively execute legacy 32-bit PowerPC instructions when running in
big-endian mode. Most Power ISA support has shifted (pun intended) to
little-endian mode, so there are few remaining operating systems that
support big-endian mode. Debian is one of them, however (albeit
unofficially.)
|
|
|
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.
|
|
|
fad61007
|
2024-08-20T18:52:53
|
|
Replace TJExample with IJG workalike programs
|
|
|
e69dd40c
|
2024-01-23T13:26:41
|
|
Reorganize source to make things easier to find
- Move all libjpeg documentation, except for README.ijg, into the doc/
subdirectory.
- Move the TurboJPEG C API documentation from doc/html/ into
doc/turbojpeg/.
- Move all C source code and headers into a src/ subdirectory.
- Move turbojpeg-jni.c into the java/ subdirectory.
Referring to #226, there is no ideal solution to this problem. A
semantically ideal solution would have involved placing all source code,
including the SIMD and Java source code, under src/ (or perhaps placing
C library source code under lib/ and C test program source code under
test/), all header files under include/, and all documentation under
doc/. However:
- To me it makes more sense to have separate top-level directories for
each language, since the SIMD extensions and the Java API are
technically optional features. src/ now contains only the code that
is relevant to the core C API libraries and associated programs.
- I didn't want to bury the java/ and simd/ directories or add a level
of depth to them, since both directories already contain source code
that is 3-4 levels deep.
- I would prefer not to separate the header files from the C source
code, because:
1. It would be disruptive. libjpeg and libjpeg-turbo have
historically placed C source code and headers in the same
directory, and people who are familiar with both projects (self
included) are used to looking for the headers in the same directory
as the C source code.
2. In terms of how the headers are used internally in libjpeg-turbo,
the distinction between public and private headers is a bit fuzzy.
- It didn't make sense to separate the test source code from the library
source code, since there is not a clear distinction in some cases.
(For instance, the IJG image I/O functions are used by cjpeg and djpeg
as well as by the TurboJPEG API.)
This solution is minimally disruptive, since it keeps all C source code
and headers together and keeps java/ and simd/ as top-level directories.
It is a bit awkward, because java/ and simd/ technically contain source
code, even though they are not under src/. However, other solutions
would have been more awkward for different reasons.
Closes #226
|
|
|
abeca1f0
|
2023-11-30T09:35:11
|
|
Move official releases to GitHub
|
|
|
762f8b4f
|
2023-07-05T10:55:07
|
|
Doc: Mention that we are a JPEG ref implementation
|
|
|
b5a9ef64
|
2022-11-13T13:00:26
|
|
Don't allow 12-bit JPEG support to be disabled
In libjpeg-turbo 2.1.x and prior, the WITH_12BIT CMake variable was used
to enable 12-bit JPEG support at compile time, because the libjpeg API
library could not handle multiple JPEG data precisions at run time. The
initial approach to handling multiple JPEG data precisions at run time
(7fec5074f962b20ed00b4f5da4533e1e8d4ed8ac) created a whole new API,
library, and applications for 12-bit data precision, so it made sense to
repurpose WITH_12BIT to allow 12-bit data precision to be disabled.
e8b40f3c2ba187ba95c13c3e8ce21c8534256df7 made it so that the libjpeg API
library can handle multiple JPEG data precisions at run time via a
handful of straightforward API extensions. Referring to
6c2bc901e27b047440ed46920c4d3f0480b48268, it hasn't been possible to
build libjpeg-turbo with both forward and backward libjpeg API/ABI
compatibility since libjpeg-turbo 1.4.x. Thus, whereas we retain full
backward API/ABI compatibility with libjpeg v6b-v8, forward libjpeg
API/ABI compatibility ceased being realistic years ago, so it no longer
makes sense to provide compile-time options that give a false sense of
forward API/ABI compatibility by allowing some (but not all) of our
libjpeg API extensions to be disabled. Such options are difficult to
maintain and clutter the code with #ifdefs.
|
|
|
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.
|
|
|
6c2bc901
|
2022-11-03T14:39:19
|
|
Don't allow disabling in-memory src/dest managers
By default, libjpeg-turbo 1.3.x and later have enabled the in-memory
source/destination manager functions from libjpeg v8 when emulating the
libjpeg v6b or v7 API/ABI, which has allowed operating system
distributors to provide those functions without adopting the
backward-incompatible libjpeg v8 API/ABI.
Prior to libjpeg-turbo 1.5.x, it made sense to allow users to disable
the in-memory source/destination manager functions at build time and
thus retain both backward and forward API/ABI compatibility relative to
libjpeg v6b or v7. Since then, however, we have introduced several new
libjpeg API functions that break forward API/ABI compatibility, so it no
longer makes sense to allow the in-memory source/destination managers to
be disabled. libjpeg-turbo only claims to be
backward-API/ABI-compatible, i.e. to allow applications built against
libjpeg or an older version of libjpeg-turbo to work properly with the
current version of libjpeg-turbo.
|
|
|
8a3b0f70
|
2022-06-24T15:21:51
|
|
Implement 12-bit-specific error/warn/trace macros
The macros in jerror.h refer to j_common_ptr, so it is unfortunately
necessary to introduce a 12-bit-specific version of that header file
(j12error.h) with 12-bit specific ERREXIT*(), WARNMS*(), and
TRACEMS*() macros. (The message table is still shared between 8-bit and
12-bit implementations.)
Fixes #607
|
|
|
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.)
|
|
|
97a1575c
|
2021-07-07T14:38:17
|
|
RPM: Don't include system lib dir in file list
This resolves a conflict between the RPM generated by the libjpeg-turbo
build system and the Red Hat 'filesystem' RPM if
CMAKE_INSTALL_LIBDIR=/usr/lib[64]. This code was largely borrowed from
the VirtualGL RPM spec. (I can legally do that because I hold the
copyright on VirtualGL's implementation.)
Fixes #532
|
|
|
1388ad67
|
2020-12-08T21:25:47
|
|
Build: Officially support Ninja
|
|
|
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.
|
|
240ba417
|
2020-01-07T16:40:32
|
|
Neon: Intrinsics impl. of prog. Huffman encoding
The previous AArch64 GAS implementation has been removed, since the
intrinsics implementation provides the same or better performance.
There was no previous AArch32 GAS implementation.
|
|
|
cd342acf
|
2020-10-27T16:42:14
|
|
Merge branch 'master' into dev
|
|
|
d27b935a
|
2020-10-27T15:04:39
|
|
Consistify formatting to simplify checkstyle
The checkstyle script was hastily developed prior to libjpeg-turbo 2.0
beta1, so it has a lot of exceptions and is thus prone to false
negatives. This commit eliminates some of those exceptions.
|
|
|
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
|
|
|
ea8f643c
|
2020-10-14T16:30:44
|
|
Build: Remove lib32 symlink from official Mac pkg
(oversight from 4c5a15c362a951a66066521bd049728116eb7ead)
|
|
|
ae08115d
|
2020-10-15T10:25:46
|
|
Merge branch 'master' into dev
|
|
b5a14727
|
2020-10-15T10:22:51
|
|
Build: Fix permissions
|
|
|
fb6f5e8b
|
2020-06-25T21:31:11
|
|
Java/Mac:Remove obsolete libturbojpeg.jnilib alias
IIRC, this was only necessary with the version of Java 1.5 that shipped
with OS X 10.4 "Tiger". Apple's implementation of Java 6 ("Java for
OS X Systems") supported both .jnilib and .dylib extensions for JNI
libraries, but Oracle's implementation of Java has only ever supported
the .dylib extension.
|
|
|
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
|
|
|
6aabca86
|
2020-02-11T12:47:12
|
|
Merge branch 'master' into dev
|
|
|
70327296
|
2020-02-07T17:04:30
|
|
makemacpkg.in: Allow universal DMG w/o ARMv8 arch
(buglet)
|
|
|
c4675d62
|
2019-12-31T00:42:53
|
|
Merge branch 'master' into dev
|
|
|
29f718ee
|
2019-12-31T00:06:11
|
|
README.md, package specs: Various tweaks
- Don't enumerate the types of SIMD instructions that libjpeg-turbo
supports, as this can change without notice.
- Use more clear terminology when describing support for libjpeg v7/v8
features ("libjpeg" is, colloquially but not officially, the name for
the IJG's software, whereas the "libjpeg API" refers to our emulation
of said software.)
- "PhotoShop" = "Photoshop" (StudLy Caps Police)
- Adjust dynamic library versions to reflect the addition of
jpeg_read_icc_profile() and jpeg_write_icc_profile() in
libjpeg-turbo 2.0.x.
|
|
|
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
|
|
|
0d7818d1
|
2019-02-13T16:22:18
|
|
rpm.spec.in: Fix "File listed twice" warning/error
%{_libdir}/pkgconfig is a directory and should thus be prefixed by
%{dir} (oops.) This issue caused the debuginfo build under RHEL 8
(which is apparently now enabled by default-- regardless of whether the
RPM actually contains debug info, but that's another matter) to fail
with:
RPM build errors:
File listed twice: /opt/libjpeg-turbo/lib64/pkgconfig/libjpeg.pc
File listed twice: /opt/libjpeg-turbo/lib64/pkgconfig/libturbojpeg.pc
|
|
|
4b67db4d
|
2019-02-13T15:20:34
|
|
rpm.spec.in: Fix doc packaging issues w/ RHEL 7+
On RHEL 7 and later (not sure exactly whether this is a product of the
newer RPM release or something distro-specific), macros are lazily
expanded, so we need to set _docdir using %global (which expands at
definition time) and prior to _prefix and _datarootdir (which affect
_defaultdocdir.) Otherwise, _docdir is set to a subdirectory of
/opt/libjpeg-turbo/share/doc or /opt/libjpeg-turbo/doc. The former
(which happens on RHEL 7) leads to incorrect documentation packaging
(the docs should be packaged under /usr/share/doc per Red Hat
standards), and the latter (which happens on RHEL 8) leads to an RPM
build error.
|
|
|
f70a7e1e
|
2019-02-12T15:37:21
|
|
rpm.spec.in: Update deprecated [Build]Prereq tags
AFAICT, Requires and BuildRequires subsumed the functionality of Prereq
and BuildPrereq in RPM 4.0, and none of the platforms we support with
libjpeg-turbo 2.0.x has RPM < 4.4.
|
|
|
504a295c
|
2018-10-11T15:13:34
|
|
Include .pc files in LJT SDKs for Visual C++
These are apparently useful in certain esoteric build environments.
Closes #296
|
|
|
450306a8
|
2018-04-06T18:31:17
|
|
READMEs: Mention that prog JPEG is now accelerated
|
|
|
e15a6b4e
|
2018-03-23T11:14:50
|
|
Include .pc and man files in MinGW install[er]s
These files are potentially useful to MinGW users, since MSYS2 MinGW
environments have a man command by default and provide an easy way to
install pkg-config.
Closes #223
|
|
|
ca566421
|
2018-03-23T11:04:45
|
|
release/installer.nsi.in: Remove extraneous quotes
These don't seem to affect anything, because $INSTDIR is already quoted
per 25758055ac74db8edb0486c256fe11539086498f.
|
|
|
84fbd4f1
|
2018-03-17T00:27:49
|
|
Merge branch 'master' into dev
|
|
|
25758055
|
2018-03-16T20:34:18
|
|
Win installer: allow install directories w/ spaces
|
|
|
8c40ac8a
|
2017-11-16T18:46:01
|
|
Add TurboJPEG C example and clean up Java example
Also rename example.c --> example.txt and add a disclaimer to that file
so people will stop trying to compile it.
|
|
|
3d72522a
|
2017-09-20T18:11:03
|
|
SRPM build: Define _libdir based on build arch
Setting _libdir to CMAKE_INSTALL_FULL_LIBDIR only works when doing an
in-tree RPM build. SRPMs are architecture-agnostic, so the spec needs
to compute_libdir at the time the SRPM is rebuilt, not at the time it
is generated.
This is a regression introduced when implementing the new CMake-based
cross-platform build system.
|
|
|
f0dd80f2
|
2017-09-20T17:13:46
|
|
Merge branch 'master' into dev
|
|
|
fd778bba
|
2017-09-19T20:01:34
|
|
Fix PowerPC 32-bit RPM build
|
|
|
8d403aeb
|
2017-09-19T13:03:49
|
|
Fix 32-bit RPM build w/ newer RHEL/Fedora releases
The version of RPM on RHEL 5 and older platforms defines _libdir
as %{_exec_prefix}/%{_lib}, so defining _lib in the spec file redefined
_libdir. However, newer versions of RPM (probably >= 4.6, since that
was the version that introduced the ISA macros) define _libdir as either
%{_prefix}/lib or %{_prefix}/lib64. Thus, we need to explicitly
override _libdir in our spec file.
|
|
|
01b74c10
|
2017-09-11T10:06:22
|
|
Packaging: Use parallel make when rebuilding SRPM
|
|
|
11426a87
|
2016-12-10T09:10:57
|
|
Packaging system: "PACKAGE_NAME" = "PKGNAME"
Using PACKAGE_NAME as a variable name made more sense with autotools,
but now it's more of an inconvenience variable than a convenience
variable.
|
|
|
67ad5350
|
2016-12-10T09:00:39
|
|
Build: Don't require sudo for `make tarball`
The whole point of `make tarball` is to make it easy for users to create
a binary distribution of libjpeg-turbo on platforms that aren't
supported by our official build system, so requiring root permissions
somewhat defeated that purpose. Intead, the script now attempts to
detect whether the system has GNU tar or a recent version of BSD tar
that supports setting the ownership of the files in the tarball.
|
|
|
6c6696e5
|
2016-12-09T17:12:12
|
|
Mac pkg: Use PKGNAME for documentation directory
Although there is little chance that we will ever have a package
conflict on OS X, the convention from our Linux packages is to use the
package name, not the project name, for the name of the documentation
directory.
|
|
|
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
|
|
|
261db770
|
2016-12-03T15:51:58
|
|
Packaging: Use correct name for SRPM spec file
Per convention, the file should be named {package name}.spec.
|
|
|
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/
|
|
|
0ff7da71
|
2016-11-16T15:55:12
|
|
Advertise the new AVX2 SIMD extensions
(our story so far ...)
|
|
|
aefd8b79
|
2016-02-14T17:20:30
|
|
Clean up pkgconfig dir when removing RPM & Mac pkg
|
|
|
53c635b8
|
2016-02-08T14:03:13
|
|
Fix 'make dist'; Include LICENSE.md in packages
|
|
|
fe11699d
|
2016-02-03T14:02:13
|
|
Adjust performance claims
Document the latest benchmarks on the Nexus 5X and change the "2-4x"
overall claim to "2-6x". The peak performance on x86 platforms was
already closer to 5x, and the addition of SIMD-accelerated Huffman
encoding gave it that extra push over the cliff.
|
|
|
8af3f8a9
|
2016-01-18T16:40:07
|
|
Provide pkg-config (.pc) scripts
This allows a project to use PKG_CHECK_MODULES() in its configure.ac
file to easily check for the presence of libjpeg-turbo and modify the
compiler/linker flags accordingly. Note that if a project relies solely
on pkg-config to check for libjpeg-turbo, then it will not be possible
to build that project using libjpeg or an earlier version of
libjpeg-turbo.
Closes #53
Based on:
https://github.com/cberner/libjpeg-turbo/commit/496713871939b550d00005b4042420da41641a0a
|
|
|
7e3acc0e
|
2015-10-10T10:25:46
|
|
Rename README, LICENSE, BUILDING text files
The IJG README file has been renamed to README.ijg, in order to avoid
confusion (many people were assuming that that was our project's README
file and weren't reading README-turbo.txt) and to lay the groundwork for
markdown versions of the libjpeg-turbo README and build instructions.
|
|
2e2ea8e0
|
2015-01-16T03:21:05
|
|
Document AltiVec extensions
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1508 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
c4930d8b
|
2015-01-07T01:19:49
|
|
Oops. Delete the duplicate copy of [lib]turbojpeg.dll in the binary directory when uninstalling the package.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1477 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
6e6b28c3
|
2014-12-19T17:34:30
|
|
Include ARMv8 binaries when generating a combined OS X/iOS package using 'make iosdmg'
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1452 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
ceb552a9
|
2014-12-19T10:44:09
|
|
Add iOS architectures to the shared libraries generated by the Mac/iOS packaging system. I have no idea how useful this is for "standard" iOS application development, but it is useful in a jailbreak environment, and iOS 8 supposedly allows shared libs in "official" apps as well.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1447 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
eca0637c
|
2014-11-06T09:32:38
|
|
Remove trailing spaces
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1412 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
3d518989
|
2014-08-22T17:21:09
|
|
Don't use sudo when building a Debian package unless the user is non-root
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1381 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
9b012bd0
|
2014-08-22T14:15:08
|
|
Don't use sudo when building a Debian package unless the user is non-root
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1377 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
82145554
|
2014-07-17T08:25:32
|
|
Include "Installed-Size" field in the deb-control file to prevent Ubuntu from complaining
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1330 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
d762c19b
|
2014-07-17T08:24:58
|
|
Include "Installed-Size" field in the deb-control file to prevent Ubuntu from complaining
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1329 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
b1068fa2
|
2014-03-23T17:53:07
|
|
Migrate Mac packaging system to pkgbuild, since PackageMaker is no longer supported.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1212 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
f67c04c0
|
2014-03-22T20:51:38
|
|
Since we're now maintaining our own Cygwin pseudo-repository directories instead of recommending that users install these packages from a local source, it makes more sense to name the packages according to Cygwin specs, so they can be copied as-is into the pseudo-repository.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1204 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
7a9faaef
|
2014-03-21T23:34:53
|
|
Since we're now maintaining our own Cygwin pseudo-repository directories instead of recommending that users install these packages from a local source, it makes more sense to name the packages according to Cygwin specs, so they can be copied as-is into the pseudo-repository.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1195 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
d7943602
|
2014-03-21T11:01:00
|
|
RHEL 6 (and probably other platforms as well) sets _defaultdocdir=%{_datadir}/doc, which screws things up, since we're overriding _datadir. Since we intend _defaultdocdir to be /usr/share/doc, just be explicit about it.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1194 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
3064cf74
|
2014-03-21T11:00:00
|
|
RHEL 6 (and probably other platforms as well) sets _defaultdocdir=%{_datadir}/doc, which screws things up, since we're overriding _datadir. Since we intend _defaultdocdir to be /usr/share/doc, just be explicit about it.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1193 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
7308ffee
|
2013-09-26T07:29:20
|
|
Name the package *cygwin64.tar.bz2 when building on Cygwin64.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1044 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
94b6c02d
|
2013-09-26T07:27:56
|
|
Name the package *cygwin64.tar.bz2 when building on Cygwin64.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1043 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
6eb29ddb
|
2013-09-20T01:11:40
|
|
Oops. We need to delete the new copy of turbojpeg.dll in the binary directory. Also add quotes to InstDir to allow installing under "c:\Program Files\", and remove unnecessary quotes in the Delete directives.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1028 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
ae8d0dc3
|
2013-09-19T22:57:18
|
|
In the Windows installer packages, place a duplicate copy of turbojpeg.dll in c:\libjpeg-turbo[-gcc][64]\bin. This is mainly to give installers an easy way to find the DLL for the purposes of bundling it. Specifically, this was necessary for TurboVNC, becuase 32-bit CMake running on 64-bit Windows cannot ever access the "real" c:\windows\system32 directory.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1027 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
4d877931
|
2013-09-19T22:55:57
|
|
In the Windows installer packages, place a duplicate copy of turbojpeg.dll in c:\libjpeg-turbo[-gcc][64]\bin. This is mainly to give installers an easy way to find the DLL for the purposes of bundling it. Specifically, this was necessary for TurboVNC, becuase 32-bit CMake running on 64-bit Windows cannot ever access the "real" c:\windows\system32 directory.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1026 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
b9271037
|
2013-07-07T04:43:49
|
|
Fix lintian warning about missing maintainer address when installing on recent Debian-based systems
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@992 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
822c8507
|
2013-07-07T04:42:56
|
|
Fix lintian warning about missing maintainer address when installing on recent Debian-based systems
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@991 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
fca3e726
|
2013-05-04T04:48:27
|
|
Make sure the RPM provides "libjpeg-turbo" as well, for backward compatibility (the TurboVNC RPM build, in particular, checks for this.)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@979 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
04e0a029
|
2013-05-01T06:03:53
|
|
Make sure the RPM provides "libjpeg-turbo" as well, for backward compatibility (the TurboVNC RPM build, in particular, checks for this.)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@978 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
9495a944
|
2013-05-01T05:48:22
|
|
Fix 'make rpm'
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@977 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
45789538
|
2013-04-24T23:39:37
|
|
For consistency, allow the name of the Mac and Cygwin packages to be overridden as well.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@953 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
441308cf
|
2013-04-24T05:26:42
|
|
Move the TurboJPEG DLLs back into the system directory on Windows platforms. For Windows, it doesn't really simplify the build system to install these libraries in c:\libjpeg-turbo*, and it introduces potential problems with loading the JNI library. Specifically, if a user linked their Java app against the 64-bit libjpeg-turbo SDK and then used a 32-bit JVM at run time, they would not be able to load the 32-bit turbojpeg.dll without manipulating java.library.path or the PATH environment (and vice versa for building against the 32-bit libjpeg-turbo SDK and using a 64-bit JVM at run time.)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@949 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
7175e517
|
2013-04-23T22:29:00
|
|
Further enhancements/fixes to the packaging system:
-- The Mac and Cygwin packages will now be created with the directory structure defined by the configure variables "prefix", "bindir", "libdir", etc., with the exception that the docs are always installed under /usr/share/doc/{package_name}-{version} on Cygwin and /Library/Documentation/{package_name} on Mac.
-- Fixed a duplicate filename warning when generating RPMs with the default prefix of /opt/libjpeg-turbo.
-- Moved the TurboJPEG libraries out of the system directory on Windows and Mac. It is no longer necessary to put them there, since we are not trying to be backward compatible with TurboJPEG/IPP anymore.
-- Fixed an issue whereby building the "installer" target on Windows would not build the Java JAR file, thus causing an error if the JAR had not been previously built.
-- Building the "install" target on Windows will now install libjpeg-turbo into c:\libjpeg-turbo[-gcc][64] (the same directories used by the installers.) This can be overridden by setting CMAKE_INSTALL_PREFIX.
-- The Java classes on all platforms will now look for the JNI library in the directory under which the build/packaging system installs it.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@946 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
764e1e23
|
2013-04-19T04:25:14
|
|
Overhaul Linux/Unix packaging system, primarily to avoid conflicts with vendor-supplied libjpeg-turbo packages (such as in Fedora and RHEL 6.) This also streamlines the packaging system somewhat, since it is no longer necessary to move the TurboJPEG libraries into the system library directory. Relocating those libraries was originally done to provide backward compatibility with TurboJPEG/IPP, but that package is long obsolete, and the software that formerly used it has been linking statically with libjpeg-turbo for quite some time.
If the default prefix (/opt/libjpeg-turbo) is used, then we now always install 32-bit libraries in /opt/libjpeg-turbo/lib32 and 64-bit libraries in /opt/libjpeg-turbo/lib64 instead of trying to conform to the Debian or Red Hat conventions. The RPM and DEB packages will now be created with the directory structure defined by the configure variables "prefix", "bindir", "libdir", etc., with the exception that the docs are always installed under /usr/share/doc/{package_name}-{version}.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@944 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
a35de7cc
|
2013-02-04T23:46:52
|
|
Fix line break
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@925 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
a2a2cd60
|
2013-02-04T22:29:57
|
|
Include ARM v7s (iPhone 5, iPad 4) support in the universal libjpeg/libturbojpeg libraries distributed with our official binary package for OS X.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@923 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
0f7ff719
|
2013-01-23T01:32:25
|
|
Wordsmith the project description
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@921 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
6da61db2
|
2013-01-19T01:06:46
|
|
Fix several issues with SRPM generation: (1) ensure that all relevant configure arguments get passed down to the configure command line in the generated spec file, (2) adjust the file manifest in the spec to accommodate the differing "age" version whenever the in-memory source/dest managers are used, and (3) fix an issue with the value of SO_MAJOR_VERSION passed down to the configure command line in the generated spec file (SO_MAJOR_VERSION has to remain pure, so we use a different variable to pass down the combined "current+age" value to libtool in Makefile.am.)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@916 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
d5e964c9
|
2013-01-10T11:47:39
|
|
Wordsmithing; Remove mention of TurboJPEG/IPP-- it is no longer a relevant comparison, since the version of IPP on which TurboJPEG/IPP was based is now quite old, and TurboJPEG/IPP is no longer distributed or supported by The VirtualGL Project; Include information about mathematical incompatibilities with jpeg-8
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@893 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
a394bf75
|
2012-08-07T18:44:24
|
|
Allow the libjpeg-turbo32 package to be used on MultiArch-compatible systems without overriding the linker path or LD_LIBRARY_PATH.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@858 632fc199-4ca6-4c93-a231-07263d6284db
|