Build depends are target packages that are needed at build-time for,
e.g., static libraries to link against, header files to include, &c.
Tool depends are native packages that are needed at build-time for,
e.g., compilers/linkers/&c. to run.
ok agc
Always use xorg-cf-files and imake from pkgsrc, replacing xpkgwedge.
Always install man pages, not cat pages when using imake.
Unify the various imake PLIST variables in preparation for dropping.
Adjust xbattbar for the new expectations.
environment.
Otherwise BSD style packages will use the install(1) which
bootstrap-mk-files' sys.mk picked, rather than the one from
TOOLS_PLATFORM.install (which may be specified by the user in mk.conf).
Just because a package has BSD style Makefile doesn't mean it has manpages.
A sweep of packages with USE_BSD_MAKEFILE=yes is forthcoming;
USE_TOOLS+=groff nroff will be added where appropriate.
Don't add ${X11BASE}/bin to PATH, don't include mk/x11.buildlink3.mk
when USE_X11BASE is set and don't use BUILDLINK_X11_DIR and related
magic.
OKed by wiz@
itools, intltool, diff3, sdiff, msgmerge
* Adding USE_TOOLS+=itools to a package Makefile will cause the
tool-directory versions of imake, makedepend, mkdirhier and xmkmf
to point to the ones from the devel/nbitools package.
This change will remove the need for nbitools/buildlink3.mk, which
currently does a bit of hackery to force the "right" imake tools to
be used by packages that need it.
* Adding USE_TOOLS+=intltool to a package Makefile will cause the
local versions of intltool-* inside ${WRKSRC} to be replaced by
copies from the textproc/intltool package. If "intltool" is not
specified as a tool, then we create "broken" intltool-* tools in
the tools directory to help highlight hidden dependencies on the
intltool package.
In addition, modify the tools framework so that if "perl" is not
specified as a tool, then we create a "broken" perl tool in the
tools directory for the same reason as for "intltool".
These two changes together will remove the need for
intltools/buildlink3.mk and should also catch all cases where the
sources' intltools may have been silently used because perl was
found on the system.
* Adding USE_TOOLS+=diff3, USE_TOOLS+=sdiff, or USE_TOOLS+=msgmerge
to a package Makefile will cause the corresponding tool to be pulled
into the tools directory.
These are convenience tools to help simplify dependencies for some
packages.
than pkgsrc's current one. This is an important lead-up to any project
that redesigns the pkg_* tools in that it doesn't tie us to past design
(mis)choices. This commit mostly deals with rearranging code, although
there was a considerable amount of rewriting done in cases where I
thought the code was somewhat messy and was difficult to understand.
The design I chose for supporting multiple package system flavors is
that the various depends, install, package, etc. modules would define
default targets and variables that may be overridden in files from
pkgsrc/mk/flavor/${PKG_FLAVOR}. The default targets would do the
sensible thing of doing nothing, and pkgsrc infrastructure would rely
on the appropriate things to be defined in pkgsrc/mk/flavor to do the
real work. The pkgsrc/mk/flavor directory contains subdirectories
corresponding to each package system flavor that we support. Currently,
I only have "pkg" which represents the current pkgsrc-native package
flavor. I've separated out most of the code where we make assumptions
about the package system flavor, mostly either because we directly
use the pkg_* tools, or we make assumptions about the package meta-data
directory, or we directly manipulate the package meta-data files, and
placed it into pkgsrc/mk/flavor/pkg.
There are several new modules that have been refactored out of bsd.pkg.mk
as part of these changes: check, depends, install, package, and update.
Each of these modules has been slimmed down by rewriting them to avoid
some recursive make calls. I've also religiously documented which
targets are "public" and which are "private" so that users won't rely
on reaching into pkgsrc innards to call a private target.
The "depends" module is a complete overhaul of the way that we handle
dependencies. There is now a separate "depends" phase that occurs
before the "extract" phase where dependencies are installed. This
differs from the old way where dependencies were installed just before
extraction occurred. The reduce-depends.mk file is now replaced by
a script that is invoked only once during the depends phase and is
used to generate a cookie file that holds the full set of reduced
dependencies. It is now possible to type "make depends" in a package
directory and all missing dependencies will be installed.
Future work on this project include:
* Resolve the workflow design in anticipation of future work on
staged installations where "package" conceptually happens before
"install".
* Rewrite the buildlink3 framework to not assume the use of the
pkgsrc pkg_* tools.
* Rewrite the pkginstall framework to provide a standard pkg_*
tool to perform the actions, and allowing a purely declarative
file per package to describe what actions need to be taken at
install or deinstall time.
* Implement support for the SVR4 package flavor. This will be
proof that the appropriate abstractions are in place to allow
using a completely different set of package management tools.
msgfmt, then it should set the following in the package Makefile:
USE_TOOLS+= msgfmt
To deal with message files that use the "msgid_plural" statement,
which isn't supported in NetBSD<=3.x and also in gettext<=0.10.35, we
determine if the built-in "msgfmt" is sufficiently new enough to
understand "msgid_plural". If it isn't, then we use the msgfmt.sh
script to transform the msgid_plural statements to an equivalent
construct that's understood by older msgfmt tools.
The msgfmt.sh script is a straightforward translation of the original
perl script msgfmt.pl script by Julio M. Merino Vidal into shell and
awk, which are more lightweight dependencies than perl.
We remove the USE_MSGFMT_PLURALS bits in gettext-lib/builtin.mk as they
are made obsolete by the new code in mk/tools/msgfmt.mk.
BUILD_USE_MSGFMT is still supported but will be removed in a separate
commit.
scriptlet to manage the info-file registration. The new scriptlet's
template is install/info-files. Remove obsolete texinfo.mk and
install/install-info.
No changes to package Makefiles are necessary -- the re-implementation
is internal to pkgsrc infrastructure.
makeinfo if no native makeinfo executable exists. Honor TEXINFO_REQD
when determining whether the native makeinfo can be used.
* Remove USE_MAKEINFO and replace it with USE_TOOLS+=makeinfo.
* Get rid of all the "split" argument deduction for makeinfo since
the PLIST module already handles varying numbers of split info files
correctly.
NOTE: Platforms that have "makeinfo" in the base system should check
that the makeinfo entries of pkgsrc/mk/tools.${OPSYS}.mk are
correct.
some platforms, which includes all non-ELFs and many ELF-like platforms
(that still use a.out naming conventions).
Since a branch is coming, bump the version in a blanket rather than per
platform.
too early for pkgsrc to adequately cope. In this case, imake-check.mk
was marking "imake" as a tool that was used to perform some tests.
This was causing xpkgwedge to be unnecessarily marked as a build
dependency since using imake in pkgsrc pretty much requires xpkgwedge.
However, in the case where we are running the "imake checks", we don't
need xpkgwedge around.
Solve this issue by marking all the tools in imake-check.mk with
":pkgsrc", and modify the xpkgwedge dependency test to not care about
"imake:pkgsrc".
compiler (CC/CXX) if we're actually using imake to generate Makefiles
for building and installing software. This fixes errors in various
KDE-3.x packages that use imake for other purposes.
Several changes are involved since they are all interrelated. These
changes affect about 1000 files.
The first major change is rewriting bsd.builtin.mk as well as all of
the builtin.mk files to follow the new example in bsd.builtin.mk.
The loop to include all of the builtin.mk files needed by the package
is moved from bsd.builtin.mk and into bsd.buildlink3.mk. bsd.builtin.mk
is now included by each of the individual builtin.mk files and provides
some common logic for all of the builtin.mk files. Currently, this
includes the computation for whether the native or pkgsrc version of
the package is preferred. This causes USE_BUILTIN.* to be correctly
set when one builtin.mk file includes another.
The second major change is teach the builtin.mk files to consider
files under ${LOCALBASE} to be from pkgsrc-controlled packages. Most
of the builtin.mk files test for the presence of built-in software by
checking for the existence of certain files, e.g. <pthread.h>, and we
now assume that if that file is under ${LOCALBASE}, then it must be
from pkgsrc. This modification is a nod toward LOCALBASE=/usr. The
exceptions to this new check are the X11 distribution packages, which
are handled specially as noted below.
The third major change is providing builtin.mk and version.mk files
for each of the X11 distribution packages in pkgsrc. The builtin.mk
file can detect whether the native X11 distribution is the same as
the one provided by pkgsrc, and the version.mk file computes the
version of the X11 distribution package, whether it's built-in or not.
The fourth major change is that the buildlink3.mk files for X11 packages
that install parts which are part of X11 distribution packages, e.g.
Xpm, Xcursor, etc., now use imake to query the X11 distribution for
whether the software is already provided by the X11 distribution.
This is more accurate than grepping for a symbol name in the imake
config files. Using imake required sprinkling various builtin-imake.mk
helper files into pkgsrc directories. These files are used as input
to imake since imake can't use stdin for that purpose.
The fifth major change is in how packages note that they use X11.
Instead of setting USE_X11, package Makefiles should now include
x11.buildlink3.mk instead. This causes the X11 package buildlink3
and builtin logic to be executed at the correct place for buildlink3.mk
and builtin.mk files that previously set USE_X11, and fixes packages
that relied on buildlink3.mk files to implicitly note that X11 is
needed. Package buildlink3.mk should also include x11.buildlink3.mk
when linking against the package libraries requires also linking
against the X11 libraries. Where it was obvious, redundant inclusions
of x11.buildlink3.mk have been removed.
Plan:
(1) Change USE_PERL5=build into USE_TOOLS+=perl.
(2) Change all other USE_PERL5 into including perl5/buildlink3.mk.
Possibly, for packages that don't actually build anything with perl,
but merely require it for the perl interpreter, we can instead do:
USE_TOOLS+= perl
TOOLS_DEPMETHOD.perl= DEPENDS
but this is more verbose than simply including the perl5/buildlink3.mk
file.
Move the PERL5_REQD computation into a lang/perl5/version.mk file,
and only do the USE_PERL5 logic in bsd.pkg.use.mk if we're not using
the new tools framework. This consolidates all of the perl-handling
into two places -- lang/perl5 and mk/tools/perl.mk.
in mk/tools/perl.mk since many packages expect to be able to use the
variables defined in vars.mk, but those variables can only be defined
if PERL5 is correctly defined, and that is only true after it is set
here.
them to PLIST_SUBST. They may simply be defined later on in the
Makefile processing. Instead check whether USE_PERL5 was specified
to determine whether to pass along PERL5_{SITEARCH,SITELIB,ARCHLIB}
to PLIST_SUBST.
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.
does. This allows us to use dynamic PLISTs for Perl modules that are
built using Module::Build. Bump the PKGREVISION of p5-Module-Build
to 1.
* Drop the use of PERL5_USES_MODULE_BUILD and introduce a new variable
PERL5_MODULE_TYPE that is either "MakeMaker" or "Module::Build" that
names the framework used to build/install the module.
* Split out the variables set in perl5/buildlink3.mk that are also used
by perl5/module.mk into a new file perl5/vars.mk. Move some PERL5_*
variable definitions from pkgsrc/mk/bsd.pkg.use.mk into perl5/vars.mk.
This just centralizes the common PERL5_* definitions into a single
file location.
* Convert the known packages that use Module::Build to set
PERL5_MODULE_TYPE and PERL5_PACKLIST:
devel/p5-Class-Container
devel/p5-Exception-Class
devel/p5-Log-Dispatch
devel/p5-Array-Compare
textproc/p5-Pod-Coverage
www/p5-Apache-Session-Wrapper
www/p5-MasonX-Request-WithApacheSession
