- remove LIBXAW variable. It is handled by buildlink3.mk now
- simplify patches and Makefile in packages using libXaw
- in some cases force use of Xaw3d (won't build with Xaw)
- replace some directly included of x11/Xaw3d with mk/xaw.buildlink3.mk
In next part:
- replace more includes with mk/xaw.buildlink3.mk
turned off in www/curl.
Modify the curl package to be aware of the libidn option. Ensure default
is on.
No functional change, so no version number bump.
DragonFly has two compilers in base, GCC 4.4.7 and GCC 4.7.2.
The way one switches between them for userland programs is to set
CCVER in the environment.
However, to set this via make.conf is tricky. I've been using the
low level "ALL_ENV+= CCVER=gcc47", but this trick fails to properly
identify the compiler which results in _GCC_VERSION being incorrectly
defined.
Additionally, there are some prominent packages that do not build on
gcc 4.7 and the fix is either not fully understood or would require a
large amount of work to implement. In these cases, it is desireable
to specify the package be built on gcc 4.4 regardless of CCVER setting.
To address these issues, a new directive is added: DRAGONFLY_CCVER.
It is only effective if OPSYS equals "DragonFly", and it will properly
set CCVER and properly define _GCC_VERSION. It will also allow a
per package specification of a particular compiler in the pkg makefile.
By default pkgsrc uses LOCABASE/gnu as a prefix for packages to install
native versions of GNU tools, which are them symbolically linked back to
the 'g' versions of the files in LOCALBASE, and users can then add
LOCALBASE/gnu/bin to PATH to pick up those tools.
On systems where the GNU environment is desired, PKGGNUDIR now allows
users to install the non-'g' files directly into LOCALBASE, making them
the default without having to alter PATH, whilst retaining the 'g' files
in order to ensure dependencies and tool paths remain the same.
This change modifies the algorithm used to keep track of the files that
have not yet been checksummed to use a simple loop instead of shell pattern
matching.
For packages with few distinfo entries, either way yields the same result
as the list of files to check is very short. But for those packages with
hundreds of distinfo entries (vim, I'm looking at you), the difference is
huge. In my old macppc machine, the checksum of vim used to take around
40 minutes and now it takes ~35 seconds. The difference is also clearly
visible in my faster amd64 machine (although I haven't bothered to time it).
