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.
from devel/ncurses to the mk infrastructure.
FAKE_NCURSES=yes
Provides the system curses as ncurses.h and libncurses.
USE_CURSES=wide
Links to system curses if they provide wide support, otherwise ncursesw.
wide-curses in the package options also triggers this.
This changes the buildlink3.mk files to use an include guard for the
recursive include. The use of BUILDLINK_DEPTH, BUILDLINK_DEPENDS,
BUILDLINK_PACKAGES and BUILDLINK_ORDER is handled by a single new
variable BUILDLINK_TREE. Each buildlink3.mk file adds a pair of
enter/exit marker, which can be used to reconstruct the tree and
to determine first level includes. Avoiding := for large variables
(BUILDLINK_ORDER) speeds up parse time as += has linear complexity.
The include guard reduces system time by avoiding reading files over and
over again. For complex packages this reduces both %user and %sys time to
half of the former time.
Instead, let curses.buildlink3.mk find out a usable one.
This fixes the error reported in PR 39531. However, the PR will remain
open for now because it raises another issue whether tnftp should depend
on curses or not.
always be used in other builtin.mk files.
+ In the USE_BUILTIN.* == "yes" case, set BUILDLINK_LIBNAME.* to the
corresponding BUILTIN_LIBNAME.* value so that BUILDLINK_LIBNAME.*
can always be used in other buildlink3.mk files.
that need basic termlib functionality, i.e. tgetent(), tgoto(),
tputs(), etc. Together with the termlib.builtin.mk file, they will
use either a built-in termcap library, a built-in X/Open "enhanced"
curses library, or ncurses to provide these functions.
+ Add BUILDLINK_LIBNAME.* definitions to the various curses buildlink3.mk
and builtin.mk files that give the "base" library name of the curses
library, e.g. curses, ncurses, etc. These are used by the termlib
files to set BUILDLINK_LIBNAME.termlib.
that include curses.buildlink3.mk. Generally, the rule is not to set
CURSES_DEFAULT unless it's to set it to "ncurses" or "pdcurses".
# Example mk.conf settings and their results.
# Use the system curses.
PREFER_NATIVE= yes # default value
CURSES_DEFAULT= curses # default value
# Use system "ncurses" if it's available, otherwise use devel/ncurses
# from pkgsrc.
#
PREFER_NATIVE= yes # default value
CURSES_DEFAULT= ncurses
# Use devel/ncurses from pkgsrc.
PREFER_PKGSRC= yes
# Use devel/pdcurses from pkgsrc.
PREFER_PKGSRC= yes
CURSES_DEFAULT= pdcurses
# This causes a package build failure because there is no pkgsrc
# curses.
#
PREFER_PKGSRC= yes
CURSES_DEFAULT= curses
used by packages that need curses. From curses.buildlink3.mk:
CURSES_DEFAULT
This value represents the type of curses we wish to use on the
system. Setting this to "curses" means that the system curses
implementation is fine.
Possible: curses, ncurses, pdcurses
+ Move all code to detect a built-in version of curses into a
curses.builtin.mk file.
+ Add code to {n,pd}curses/buildlink3.mk so make the headers and
libraries usable as <curses.h> and -lcurses if _PKG_USE_CURSES is
defined. _PKG_USE_CURSES is only defined by curses.buildlink3.mk.
+ Improve the detection of native ncurses in ncurses/builtin.mk and
allow headers and libraries to be usable as <ncurses.h> and -lncurses.
On Interix, force inclusion of devel/ncurses/buildlink3.mk from
mk/curses.buildlink3.mk. This forces inclusion of its builtin.mk too.
In devel/ncurses/builtin.mk, if using Interix's builtin ncurses, always
transform -lncurses to -lcurses. (-lncurses is static, but -lcurses is
shared; we want the shared version.)
by moving the inclusion of buildlink3.mk files outside of the protected
region. This bug would be seen by users that have set PREFER_PKGSRC
or PREFER_NATIVE to non-default values.
BUILDLINK_PACKAGES should be ordered so that for any package in the
list, that package doesn't depend on any packages to the left of it
in the list. This ordering property is used to check for builtin
packages in the correct order. The problem was that including a
buildlink3.mk file for <pkg> correctly ensured that <pkg> was removed
from BUILDLINK_PACKAGES and appended to the end. However, since the
inclusion of any other buildlink3.mk files within that buildlink3.mk
was in a region that was protected against multiple inclusion, those
dependencies weren't also moved to the end of BUILDLINK_PACKAGES.
curses library in some way. This file will automatically include
ncurses/buildlink[23].mk if a curses implementation isn't available. If a
package truly needs ncurses, then it should include
ncurses/buildlink[23].mk directly.
