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
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.
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)
pdf.patch and mp-tiff-patch must be fetched from my own site.
These are modified for applying after jp-extension-patch.
This problem occurs when no consistency between many patches.
Therefore, I'll integrate many many patches into a new patch. :)
