|
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.)
|
|
|
1388ad67
|
2020-12-08T21:25:47
|
|
Build: Officially support Ninja
|
|
|
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.
|
|
b5a14727
|
2020-10-15T10:22:51
|
|
Build: Fix permissions
|
|
|
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.
|
|
|
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
|
|
|
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/
|
|
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
|
|
|
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
|
|
|
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
|
|
|
0a0f8d14
|
2012-08-07T18:42:07
|
|
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/branches/1.2.x@857 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
51d626ff
|
2012-02-10T02:51:40
|
|
Don't include documentation in 32-bit supplemental package
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.2.x@801 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
a1647c84
|
2012-02-10T00:39:05
|
|
Install docs when doing 'make install' on Unix; Fix 'install' target on Windows; Include wizard.txt, example.c, and structure.txt in installed docs
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.2.x@790 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
a9b35c96
|
2011-07-19T09:52:11
|
|
Don't include JAR file in 32-bit compatibility package
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@676 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
1208d50f
|
2011-07-19T09:29:01
|
|
Trying to out-clever ourselves by having autotools generate the deb-control file broke the 32-bit supplementary DEB, so revert to the method we used in LJT 1.0 to generate this file.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@675 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
68a086a1
|
2011-07-19T09:26:23
|
|
Trying to out-clever ourselves by having autotools generate the deb-control file broke the 32-bit supplementary DEB, so revert to the method we used in LJT 1.0 to generate this file.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.1.x@674 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
9a746ad4
|
2011-05-24T17:33:06
|
|
Remove wxWindows license files from packages
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@640 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
b94f2de4
|
2011-03-22T09:31:25
|
|
Clean up packaging system
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@537 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
bfa34cf1
|
2011-03-22T01:38:04
|
|
"release/"="pkgscripts/"
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.1.x@530 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
95db4f48
|
2011-03-22T00:20:43
|
|
Clean up packaging system
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.1.x@528 632fc199-4ca6-4c93-a231-07263d6284db
|