USE_BUILDLINK3 is no longer optional (and cannot be turned off). Per mail

to tech-pkg:

=====

* USE_BUILDLINK3=YES will be unconditional.  (In fact, USE_BUILDLINK3 will
  be ignored altogether by mk/; but see below.)

* NO_BUILDLINK and NO_WRAPPER will be ignored by mk/.  If a build happens,
  these phases will happen.

* The existing NO_BUILD will imply the previous NO_BUILDLINK and NO_WRAPPER.
  If no build happens, those phases are not needed.

* NO_TOOLS will be ignored by mk/.  The tools phase, which provides much
  more than just the C compiler, will always happen regardless of package.
  This will make metapackage builds only slightly slower, in trade for far
  less user error.

2 files changed, 7 insertions, 51 deletions

diff --git a/mk/buildlink3/BUILDLINK3_DG b/mk/buildlink3/BUILDLINK3_DG
index 866ba4b8546..6f7f4d05d4d 100644
--- a/mk/buildlink3/BUILDLINK3_DG
+++ b/mk/buildlink3/BUILDLINK3_DG
@@ -1,4 +1,4 @@
-$NetBSD: BUILDLINK3_DG,v 1.6 2004/09/21 15:01:40 jlam Exp $
+$NetBSD: BUILDLINK3_DG,v 1.7 2005/03/24 17:46:01 tv Exp $
 
  0 Developer's guide to buildlink3
  =================================
@@ -59,35 +59,19 @@ to build against the viewed instance of a depoted package.
  2 Troubleshooting
  =================
 
-Q1: I'm trying to bl3ify a package but I get an error that looks like:
-
-	make: don't know how to make _BUILDLINK_USE. Stop
-
-A1: You forgot to change a reference to a buildlink2.mk file into a
-    buildlink3.mk file.
-
-
-Q2: Dependencies are added for every single buildlink3.mk file I
-    include, including for when it's supposed to use the base system
-    software.  What's going on?
-
-A2: You forgot to change USE_BUILDLINK2 to USE_BUILDLINK3 in the
-    package Makefile.
-
-
-Q3: Where can I see the actual command executed by the wrapper
+Q1: Where can I see the actual command executed by the wrapper
     scripts?
 
-A3: You should examine the contents of the ${WRKDIR}/.work.log file.
+A1: You should examine the contents of the ${WRKDIR}/.work.log file.
     The lines preceded with [*] are the commands that are intercepted
     by the wrapper scripts, and the lines preceded with <.> are the
     commands that are executed by the wrapper scripts.
 
 
-Q4: Why can't I check the values of variables set by the buildlink3
+Q2: Why can't I check the values of variables set by the buildlink3
     framework using 'make show-var VARNAME=...'?
 
-A4: Some variables are only defined for a subset of the package build
+A2: Some variables are only defined for a subset of the package build
     phases.  Try instead:
 
 	make show-var PKG_PHASE=wrapper VARNAME=...
diff --git a/mk/buildlink3/README b/mk/buildlink3/README
index 7bb37a4105e..eba31172821 100644
--- a/mk/buildlink3/README
+++ b/mk/buildlink3/README
@@ -1,4 +1,4 @@
-$NetBSD: README,v 1.5 2004/12/01 09:53:01 wiz Exp $
+$NetBSD: README,v 1.6 2005/03/24 17:46:01 tv Exp $
 
  0 Package Views
  ===============
@@ -115,36 +115,8 @@ implementation currently allows "overwrite" to depend on either
 "overwrite" or pkgviews packages, but pkgviews packages are restricted
 to only being able to depend on other pkgviews packages.
 
-Packages that have been converted to use buildlink3 should add the
-following line to their Makefiles:
-
-	USE_BUILDLINK3=	YES
-
-A package must be converted to use the buildlink3 framework before it
-can support the pkgviews installation style.
-
-
- 0.5 Package conversion issues
- =============================
-
-The conversion process for a package to use buildlink3 and pkgviews
-essentially consists of changing USE_BUILDLINK2 to USE_BUILDLINK3,
-including buildlink3.mk files instead of buildlink2.mk files, and
-adding the PKG_INSTALLATION_TYPES line to the package Makefile.  It's
-extremely easy and painless.
-
-Since the idea is that the user can choose to install a package using
-either installation style, the package Makefiles have to explicitly
-support this.  This means that "hard" packages just got harder to
-maintain, but easy packages stay about the same.  In this case, "hard"
-packages are the ones that have module packages, e.g. PHP4, perl5,
-Apache, Cyrus-SASL, etc.  A package of this type must support finding
-shared modules or configuration files in directories shared with all
-of its module packages, thus requiring some hard-coding of paths
-across different packages.
-
 
- 0.6 Future Work
+ 0.5 Future Work
  ===============
 
 There may be some way around the problem of pkgviews packages not