built-in or not into a separate builtin.mk file. The code to deal
checking for built-in software is much simpler to deal with in pkgsrc.
The buildlink3.mk file for a package will be of the usual format
regardless of the package, which makes it simpler for packagers to
update a package.
The builtin.mk file for a package must define a single yes/no variable
USE_BUILTIN.<pkg> that is used by bsd.buildlink3.mk to decide whether
to use the built-in software or to use the pkgsrc software.
this build with NetBSD make older than Dec 26 2003.
Problem was that ${FOO:$o=.lo} was not expanded as in GNU make
before that date; problem found by Thomas Dickey.
Remove USE_GNU_TOOLS+=make.
as PREFER_PKGSRC. Preferences are determined by the most specific
instance of the package in either PREFER_PKGSRC or PREFER_NATIVE. If
a package is specified in neither or in both variables, then PREFER_PKGSRC
has precedence over PREFER_NATIVE.
BUILDLINK_PREFER_PKGSRC
This variable determines whether or not to prefer the pkgsrc
versions of software that is also present in the base system.
This variable is multi-state:
defined, or "yes" always prefer the pkgsrc versions
not defined, or "no" only use the pkgsrc versions if
needed by dependency requirements
This can also take a list of packages for which to prefer the
pkgsrc-installed software. The package names may be found by
consulting the value added to BUILDLINK_PACKAGES in the
buildlink[23].mk files for that package.
other platforms (a YES should have been a NO, plus it was in the wrong
place!). This should fix PR 24129.
* Add more sophisticated ncurses version detection for platforms that
actually have real ncurses in the base system. This should be a win
for FreeBSD systems.
* Downgrade the required ncurses to 5.0. The previous bump done in
revision 1.8 wasn't necessary since ncurses never had a dependency on
libiconv.
(and manpages). This is in regards to my PR #23103.
I bumped PKGREVISION in Makefile but not in buildlink2.mk file.
The ncurses libraries and headers didn't change. No need to bump
PKGREVISIONs for all the packages that depend on libncurses.
curses.buildlink2.mk. This was wrong because we _really_ do want to
express that we want _n_curses when we include the buildlink2.mk file.
We should have a better way to say that the NetBSD curses doesn't
quite work well enough. In fact, it's far better to depend on ncurses
by default, and exceptionally note when it's okay to use NetBSD curses
for specific packages. We will look into this again in the future.
