* - deleted ports are only shown under the This port is required by section. It was harder to do for the Required section. Perhaps later...

Configuration Options

===> The following configuration options are available for xv-3.10a_16:
DOCS=on: Build and/or install documentation
M17N=off: build with Multilingualization support
===> Use 'make config' to modify these settings

New USES imake to handle the dependency on imake.
This uses accept 'env' as an argument for ports that do use their own or a
different do-configure target.
Modify xmkmf so it accept IMAKECPPFLAGS as default flags for imake and pass it
to the called imake.
Modify xorg-cf-files (the FreeBSD.cf configuration file) to allow CppCmd to be
overwritten.
Pass CppCmd CcCmd and CplusplusCmd via command line to each call of imake via
IMAKECPPFLAGS
Pass IMAKE_DEFINE with the above arguments to MAKE_ARGS so that imake spawned
from Makefile generated by a previous
imake also inherit the defined CppCmd CcCmd and CplusplusCmd.
Make imake use devel/tradcpp all the time, so that when buidling with clang we
do not depend on gcc's cpp.
Make imake respect CC and CXX
Make imake respect USE_GCC (if set imake will use gcc's cpp).
While here:
- Remove a couple of indefinite articles from comments
- Trim headers
- Fix a couple of ports to build with clang or use: USE_GCC=any
- Fix a now useless redefinition of the extraction chain
- Fix a typo in japanese/Wnn7-lib bundled imake template definitions
- Fix some XMKMF execution with no env specified
- Use options helper in x11/xautolock to simplify the port

Force numerous ports that fail to build with clang over to instead always
rely on gcc. The patch uses the new USE_GCC=any code in Mk/bsd.gcc.mk to
accomplish this.
The ports chosen were ports that blocked 2 or more ports from building with
clang. (There are several hundred other ports that still fail to build with
clang, even with this patch. This is merely one step along the way.)
Those interested in fixing these ports with clang, and have clang as their
default compiler, can simply set FORCE_BASE_CC_FOR_TESTING=yes.
For those who have gcc as their default compiler, this change is believed
to cause no change.
Hat: portmgr
Tested with: multiple runs on amd64-8-exp-bcm and 9-exp-clang, with various
combinations of patch/no-patch and flag settings.

With 24/32-bit xwd files, xv swaps the red and blue channels. With 16-bit xwd
files, the image is very dark green (almost black).
Both problems are caused by hard-coding the channel order and offsets, rather
than using the colour masks in the xwd header.
xv reads the input into a 24-bit internal image, which is then displayed. The
lack of brightness in the 16-bit display is because the colour values are copied
into the low-order bits of the internal pixmap rather than the high order bits.
The green hue is because the green channel has 6 bits, whereas red and blue only
have 5 bits, making the green twice as (relatively) bright.
The new patch solves that problem.
PR: 96971
Submitted by: Peter Jeremy <peterjeremy@optushome.com.au>
Approved by: Miguel Mendez <mmendez@gmail.com> (maintainer)

Add the software's web-site to the distinfo, which did not have the WWW entry
before. Add several more patches available on the said web-site. In
particular, use the later png-related patch (-fix3 vs. -fix2). Move some
of the patches from DISTFILES to PATCHFILES -- for some others it matters,
because of the order they have to be applied and different -p settings
necessary.