mozjpeg

ryan/mozjpeg

Fork 0

Commit Graph

Author	SHA1	Message	Date
DRC	3d625746d4	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.)	2013-04-24 05:26:42 +00:00
DRC	2de2cf9e54	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.	2013-04-23 22:29:00 +00:00
DRC	90a42bb4d2	Slight refactor to put ScalingFactor into its own class (mainly because the $ in the class name was wreaking havoc on the build scripts, but also to add a few convenience methods to it) and to create a separate loader class so we can provide a .jar file with the MinGW distribution that loads the correct DLL	2011-04-02 02:09:03 +00:00

Author

SHA1

Message

Date

DRC

3d625746d4

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.)

2013-04-24 05:26:42 +00:00

DRC

2de2cf9e54

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.

2013-04-23 22:29:00 +00:00

DRC

90a42bb4d2

Slight refactor to put ScalingFactor into its own class (mainly because the $ in the class name was wreaking havoc on the build scripts, but also to add a few convenience methods to it) and to create a separate loader class so we can provide a .jar file with the MinGW distribution that loads the correct DLL

2011-04-02 02:09:03 +00:00

3 Commits