The original check was not compliant with autoconf's syntax, did not
have a very good behaviour for user and was not easy to make evolve.
The new macro:
- uses as much as possible autoconf macros for portability and code
consistency;
- provides a consistent behaviour on yes/no/auto (if user explicitly
enables support, do not silently disable if not found; if library is found
but not the header, complain to let user install it or explicitly disable
support);
- makes uses of shell functions to keep generated configure smaller by
sharing reusable stuff;
- uses an automake conditional to avoid compiling the file is support is
not enabled
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
The optimize_for_speed was used to set the Alpha channel for jpeg.
The alpha channel for jpeg should be used always. The current CPUs/GPUs can do
it without problems and this is an old behaviour.
The functions are declared in different files but they were called
in another file which re-declared the prototypes. This is dangerous
as it can lead to misaligned prototypes when functions changes.
They are now grouped in the library internal header 'imgformat.h'
- Kill unused vars in wrlib
- Add missing initializers to defaults.c:staticOptionList
- Re-format it slightly
- Kill some dead code
- Kill stupid "if (const op var)"
for arq in `git ls-files *.c`; do
echo $arq;
indent -linux -l115 $arq;
done
The different line break at 115 columns is because
I use a widescreen monitor :-)
- Separated the font caches for normal fonts and fontsets in WINGs (they can
have the same names and collide in the cache giving unwanted results)
- Updated the years in the copyright notices
code like
*ptr++ = *ptr++ = *ptr++ = color;
is wrong, because there is no guarantee that ptr will be incremented
_between_ the assignment operations. it can be incremented after all
assignment operations as well. Because of this both of these are valid
implementations for a compiler:
a. assign, increment, assign, increment, assign, increment
b. assign, assign, assign, increment by 3
In case b. only the first memory location of the 3 will be modified, being
assigned 3 times the same value, while the other 2 remain unchanged.
For example egcs-2.91.66 (and possibly gcc-2.95.x too) implement this in
the second way (like in case b.)
Also the order in which the assignement is made is undefined (left to right
or right to left).
this fixed the problem we had with greyscale jpegs showing up in red,
and possibly other problems related to pseudocolor and greyscale displays.