These variables are for packages where populating -I/-L flags into
{C,CPP,LD}FLAGS is not enough and need to know accurate paths to
header and library directories.
This is particularly important for ncurses because its headers
sometimes reside in "${BUILDLINK_PREFIX.ncurses}/include/ncurses" and
sometimes in "${BUILDLINK_PREFIX.ncurses}/include" while no pkg-config
.pc files are available. The same goes for ncursesw.
This release adds many new features which enhance PostgreSQL's flexibility, scalability and performance for many different types of database users, including improvements to JSON support, replication and index performance.
the problem is either situational (e.g. the various RESTRICTED-like
cases) or unfixable in pkgsrc (no pthreads, ipv6, etc. on platform).
Conversely, if the wrong version of mysql is installed, that's a
PKG_FAIL_REASON.
discussion on tech-pkg.
BROKEN_ON_PLATFORM and NOT_FOR_PLATFORM are the same, except that
(now) BROKEN_ON_PLATFORM sets PKG_FAIL_REASON and NOT_FOR_PLATFORM
sets PKG_SKIP_REASON. BROKEN_EXCEPT_FOR_PLATFORM and ONLY_FOR_PLATFORM
correspond in the same way.
The idea is that going forward we will distinguish unbuildable
packages that theoretically ought to be fixed (these are BROKEN) from
packages where it doesn't make sense to build (these are NOT_FOR)...
examples of the former include most non-64-bit-clean packges; examples
of the latter include OS-specific language bindings.
A general review of the uses of NOT_FOR_PLATFORM and ONLY_FOR_PLATFORM
(converting many of them to BROKEN...) is coming up.
Similarly, a general review of the uses of PKG_FAIL_REASON and
PKG_SKIP_REASON is coming up.
For this to become useful, pbulk needs to be taught to report failing
and skipped packages differently - the idea is that failing packages
should be reported up front and skipped packages don't need to be. This
has not been done yet, but one set of things at a time...
Motivation: with "USE_CWRAPPERS=yes" on the default case-insensitive
OS X filesystem, linking the wrappers was failing, stopping the
build. For example:
===> Creating toolchain wrappers for mess822-0.58nb3
ln: .../pkgsrc-current/mail/mess822/work/.cwrapper/bin/cc: File exists
*** Error code 1
Stop.
I never noticed this with the old wrappers, but they've also been
failing to link "CC" as an alias to "c++"; it's just that the failure
has been silent and I've never noticed a build failure for lack of
a "CC" wrapper, despite there probably never having been such a
wrapper.
Given that jperkin's SmartOS bulk build with this change produced
results similar to last week's non-cwrappers trunk build, we can
conclude that across platforms, the need for a "CC" wrapper is very
limited and we needn't try (and sometimes fail) to create one by
default.
This definition controls whether the binary package which is built
during package installation will be copied to pkgsrc/packages/All.
To retain binary packages in pkgsrc/packages/All, set
PKGSRC_KEEP_BIN_PKGS=yes
in environment or MAKECONF. If this is not set, binary packages
will not be preserved after their WRKDIR is removed. This may not
be what you want.
To preserve the status quo since 2013/05/22, and just delete the
binary package after it's built, the default for PKGSRC_KEEP_BIN_PKGS
is "no", or it can be explicitly set.
As reviewed on tech-pkg.
