RECOMMENDED is removed. It becomes ABI_DEPENDS.
BUILDLINK_RECOMMENDED.foo becomes BUILDLINK_ABI_DEPENDS.foo.
BUILDLINK_DEPENDS.foo becomes BUILDLINK_API_DEPENDS.foo.
BUILDLINK_DEPENDS does not change.
IGNORE_RECOMMENDED (which defaulted to "no") becomes USE_ABI_DEPENDS
which defaults to "yes".
Added to obsolete.mk checking for IGNORE_RECOMMENDED.
I did not manually go through and fix any aesthetic tab/spacing issues.
I have tested the above patch on DragonFly building and packaging
subversion and pkglint and their many dependencies.
I have also tested USE_ABI_DEPENDS=no on my NetBSD workstation (where I
have used IGNORE_RECOMMENDED for a long time). I have been an active user
of IGNORE_RECOMMENDED since it was available.
As suggested, I removed the documentation sentences suggesting bumping for
"security" issues.
As discussed on tech-pkg.
I will commit to revbump, pkglint, pkg_install, createbuildlink separately.
Note that if you use wip, it will fail! I will commit to pkgsrc-wip
later (within day).
developer is officially maintaining the package.
The rationale for changing this from "tech-pkg" to "pkgsrc-users" is
that it implies that any user can try to maintain the package (by
submitting patches to the mailing list). Since the folks most likely
to care about the package are the folks that want to use it or are
already using it, this would leverage the energy of users who aren't
developers.
cmake not tested on DragonFly, but did build package on DragonFly.
Also hardcode "NetBSD" in PLIST instead of ${OPSYS} so deinstall
works on non-NetBSD platforms.
Bump PKGREVISION.
in the process. (More information on tech-pkg.)
Bump PKGREVISION and BUILDLINK_DEPENDS of all packages using libtool and
installing .la files.
Bump PKGREVISION (only) of all packages depending directly on the above
via a buildlink3 include.
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.
CMake is an extensible, open-source system that manages the build
process in an operating system and compiler independent manner. Unlike
many cross-platform systems, CMake is designed to be used in
conjunction with the native build environment. Simple configuration
files placed in each source directory (called CMakeLists.txt files)
are used to generate standard build files (e.g., makefiles on Unix and
projects/workspaces in Windows MSVC) which are used in the usual
way. CMake can compile source code, create libraries, generate
wrappers, and build executables in arbitrary combinations. CMake
supports in-place and out-of-place builds, and can therefore support
multiple builds from a single source tree. CMake also supports static
and dynamic library builds. Another nice feature of CMake is that it
generates a cache file that is designed to be used with a graphical
editor. For example, when CMake runs, it locates include files,
libraries, and executable, and may encounter optional build
directives. This information is gathered into the cache, which may be
changed by the user prior to the generation of the native build files.
