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.
This solves the problem of building GNU tools that explicitly or
implicitly depend on other GNU tools. This problem has presented a
bootstrap issue on platforms with few GNU tools, especially where
USE_PKGSRC_GCC is used.
Based on a patch posted by sketch on tech-pkg in December 2003.
-b Compile stubs in "backwards compatible" mode, disabling
support for transport-independent RPC. The -b should always
be specified when generating files for NetBSD, since there is
no transport-independent RPC support in NetBSD.
Therefore, force "-b" to be the first argument whenever rpcgen is invoked
via the wrapper.
The wrapper will correctly set the CPP environment variable to a
stat((2)able path to a C preprocessor, then rely on the PATH to
find and invoke the real rpcgen.
Remove NO_EXPORT_CPP in package Makefiles where it was used just to
avoid problems with rpcgen. The build system now just does the right
thing automatically without needing package-specific knowledge.
This fixes PR pkg/27272.
explicitly undef YACC.
YACC?=yacc is set in sys.mk, but this interferes with building some
packages that require bison because they try ${YACC} and fail.
(1) defs.${OPSYS}.mk --> platform/${OPSYS}.mk.
The "platform" subdirectory is where all of the ${OPSYS}-specific
infrastructure logic should reside.
(2) bsd.pkg.defaults.mk --> defaults/mk.conf
bsd.pkg.obsolete.mk --> defaults/obsolete.mk
Renaming bsd.pkg.defaults.mk to defaults/mk.conf is to mimic the way
that NetBSD has /etc/rc.conf as well as /etc/defaults/rc.conf, where
the latter is a full list of user-settable variables, and the two
files share the same name to reinforce the fact /etc/defaults/rc.conf
can be directly copied in place as /etc/rc.conf. This is the same
relationship shared by defaults/mk.conf and /etc/mk.conf.
${TOOLS_DIR}/bin. It will either point to /usr/bin/tbl or will depend
on groff otherwise.
This should allow removing dependencies on groff just for the sake of
forcing the existence of tbl.
Package Makefiles may now directly include compiler.mk.
* Don't include compiler.mk within bsd.prefs.mk any longer. It was only
included for the purposes of defining CC_VERSION. Packages that want
to test the value of CC_VERSION should now first include
"../../mk/compiler.mk". Any GCC_REQD statements in package Makefiles
should be set before compiler.mk is included.
* Simpllfy pkgsrc/mk/compiler/*.mk files as a result of not needing to
be included indirectly by bsd.prefs.mk. We remove the special handling
associated with detecting whether the file was included from within
bsd.prefs.mk. These files are now much more straightforward to write
and understand.
* G/C the BSD_PREFS_MK stack mechanism as the only users (compiler/*)
no longer need it.
* Ensure that directories are prepended to the PATH only from within
bsd.pkg.mk.
target. This still allows any autoconf/automake we execute at
pre-configure time to find its own scripts, but forces the configure script
find our stubs instead. This should prevent the need to constantly
override the missing script using GNU_MISSING_OVERRIDE.
This allows any autoconf/automake we execute at pre-configure time to find
its own scripts, yet still prevents "make build" from clobbering any
changes we may have made.
due to a type on gcc.mk that causes the ${_GCC_PREFIX}/bin to always be
prepended to the PATH. The problem that was hiding was "make" resolving
to ${TOOLS_DIR}/bin/make if the package used GNU make, which broke
building since the package Makefile is a BSD Makefile and we passed
PATH to some phases of the build. Fix this by expanding MAKE to the
full path to ${MAKE} in bsd.prefs.mk. We also garbage collect the now
useless checks for PHASES_AFTER_BUILDLINK that cluttered the PREPEND_PATH
code.
(by checking PREPEND_PATH) and only for those phases of the build that
care about the PATH (buildlink or later). We also pass the PATH to
those same phases of the build so that executing ${CC} will work correctly
from custom {pre,do,post}-* targets that occur at buildlink time or
later.
${LOCALBASE}/bin/gmake. ${LOCALBASE}/bin/${GNU_PROGRAM_PREFIX}/make
technically works, too, but this covers the (unsupported!!) case where the
user has GNU_PROGRAM_PREFIX="" and has moved the "make" binary directly
over the "gmake" symlink created by pkgsrc (Jeremy Reed reported this
problem on tech-pkg@ because he uses this a a debugging technique to find
out whether GNU make is actually needed by a package or not).
${TOOLS_DIR}/bin/make. If a package wants GNU make, then it should
set:
USE_GNU_TOOLS+= make
in the package Makefile. Allow for USE_GMAKE to continue to work
until we get a chance to sweep through pkgsrc and remove the usage
of this now-redundant variable.
This change allows us to avoid patching makefiles that use a bare
"make" command to invoke sub-make processes. Idea suggested by
salo@netbsd.org in pkg/22509.
put the tools in ${WRKDIR}/.tools/bin instead of in ${BUILDLINK_DIR},
and remove the need for buildlink2 to use USE_GNU_TOOLS. In the
modified USE_GNU_TOOLS implementation, the following implementation-
specific variables have the following meanings:
_TOOLS_REPLACE.<tool>
means that we want ${AWK}, ${SED}, etc. symlinked into
${TOOLS_DIR} as awk, sed, etc.
_TOOLS_NEED_GNU.<tool>
means that we want to use the pkgsrc version of <tool>
symlinked info ${TOOLS_DIR} as awk, sed, etc. If this is
"YES", then it always trumps _TOOLS_REPLACE.<tool>.
And we want nothing to happen if we're building the pkgsrc GNU tool
itself. The modified USE_GNU_TOOLS implementation should also
hopefully fix the circular dependency problem.
Create a new target "tools" that is run after "patch" and before
"buildlink" that populates the ${TOOLS_DIR} directory. This ensures
that it's always run at the right time, instead of relying on
pre-buildlink or pre-configure, which may be cancelled by
NO_BUILDLINK or NO_CONFIGURE.
XXX There is some possible fallout in texinfo.mk with the MAKE_ENV and
XXX CONFIGURE_ENV settings for INSTALL_INFO and MAKEINFO. It looks
XXX like the MAKE_ENV and CONFIGURE_ENV settings should move from
XXX tools.mk into texinfo.mk, and they no longer need to be
XXX conditional on USE_BUILDLINK2. I'll leave it to the texinfo.mk
XXX dude (Hi, Stoned!).
