use-xpkgwedge systems. Not needed when building within pkgsrc, but useful
if you want to link outside 3rd-party software against pkgsrc-controlled
libraries.
in the fall-through code for setting a default value for USE_BUILTIN.<pkg>.
This provides ensures that USE_BUILTIN.<pkg> is always set for every
package listed in BUILDLINK_PACKAGES. Back out previous as it's now
unneeded.
add all of the direct _and_ indirect dependencies to the DEPENDS list.
This causes "install-depends" to check that every dependency, whether
it be direct or indirect, is up-to-date. This fixes PR 24721 by Jeremy
Reed.
native use the native, non-pkgsrc-managed X11R6
XFree86 use x11/XFree86-libs (not yet implemented)
xlibs use freedesktop.org xlibs (not yet implemented)
It is used to set the X11 implementation used to build X11 packages.
/usr/pkg/share/x11-links into the buildlink directory, just rely on the
regular buildlink3 infrastructure to do it for us. This simplifies the
handling of X11 in buildlink3. The only caveat is that "x11-links"
should appear at the head of BUILDLINK_PACKAGES, and this detail is
handled by x11-links/buildlink3.mk.
BUILDLINK_RPATHDIRS.<pkg> which is a list of directories relative to
BUILDLINK_PREFIX.<pkg> to add to the library runtime search path. For
packages that are a full dependency, this defaults to
BUILDLINK_LIBDIRS.<pkg>, but for packages that are a build dependency,
this defaults to an empty list (on the theory that a build dependency
doesn't have any shared libraries required by the package at runtime).
the dependency_libs line if it ended in a "-Ldir" option. Fix by not
eating shell word separators [ \`\"':;,]. This should fix PR 24639 by
Matthias Scheler.
renamed to {USE,IS}_BUILTIN and are handled separately by the builtin.mk
files.
Create a new variable PREFER.<pkg> that lets <pkg>/builtin.mk determine
what the preference is in a simple way.
USE_BUILTIN.<pkg> before it is checked. _BLNK_PACKAGES isn't strictly
a superset of _BLNK_DEPENDS due to the special x11-links handling
which should eventually be removed altogether.
changes to the buildlink3 framework. The changes ensure that
BUILDLINK_PACKAGES orders packages so that for any element in the
list, the packages to the right do not depend on any packages to the
left of that element.
http://fink.sourceforge.net/doc/porting/shared.php
It's okay to link against a name like "libqt.2.3.0.dylib" using
"-lqt.2.3.0", which means we never need to do anything more than just
strip the trailing ".dylib" from shared library names when converting from
a full path to "-L... -l...". This should fix PR 24402.
${LOCALBASE}. Some packages' configure scripts resolve all paths to
physical paths, and since buildlink3 suppresses references outside of
${LOCALBASE}, it can break the build of those packages.
This should fix the problem noted by Nathan Williams in the thread
titled "x11/tk build failure" at:
http://mail-index.netbsd.org/tech-pkg/2004/02/17/0004.html
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.
pkg-config to only look in ${BUILDLINK_DIR}/lib/pkgconfig for *.pc files.
This will correctly hide the presence of software from configure scripts
that query pkg-config for that information.
Idea suggested by Julio M. Merino Vidal.
compiler set. This will cause the libtool configuration found in several
packages to use the correct C++ compiler even though the package doesn't
use C++. This was causing bugs when CXXFLAGS contained flags not
understood by the system gcc-2.95.3.
use LIBTOOL_OVERRIDE. In the buildlink[23] case, that is supposed to be
the one in ${BUILDLINK_DIR}. Create new private variables _LIBTOOL and
_SHLIBTOOL to hold these paths.
building of software. For packages that use either buildlink2 or
buildlink3, this would be the wrapper script in ${BUILDLINK_DIR}.
* Garbage-collect _BLNK_WRAP_SETENV.* as those are not needed after
the above changes. Configure and make processes will automatically
find the right compilers in the PATH.
* PKGLIBTOOL and PKGSHLIBTOOL are no longer needed since LIBTOOL and
SHLIBTOOL point to the correct libtools regardless of any
USE_BUILDLINK[23] definitions.
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.
BUILDLINK_PREFER_PKGSRC
This variable determines whether or not to prefer the pkgsrc
versions of software that is also present in the base system.
This variable is multi-state:
defined, or "yes" always prefer the pkgsrc versions
not defined, or "no" only use the pkgsrc versions if
needed by dependency requirements
This can also take a list of packages for which to prefer the
pkgsrc-installed software. The package names may be found by
consulting the value added to BUILDLINK_PACKAGES in the
buildlink[23].mk files for that package.
just assume they do unless they're known _not_ to work. So far, only
Darwin-5.* suffers from this problem, apparently because they use some
bizarre version of zsh for /bin/sh.
packages which pass these gcc-specific flags.
also ignore -Werror; if a package passes -Werror, it's expecting that
the compiler is gcc, which in this case it is not. SunPro often emits
warnings on code which gcc doesn't, so transforming this flag to
-errwarn is counterproductive.
several arguments together) from the command line and push it onto the
stack. Pop the top off the stack, process, and push replacement
arguments onto the stack. Repeat the last step until no more processing
is done, and we have our final argument to be passed on through to the
rest of the wrapper script.
specify library orderings with:
BUILDLINK_TRANSFORM+= reorder:l:crypt:crypto
The wrapper scripts then reorder the libraries so that -lcrypt will
always come before -lcrypto. If there are lots of reorder:l:...
commands, then the algorithm looks a bit like a topological sort.
variables are no longer saved using MAKEFLAGS since the saved values aren't
correct for recursively invoked make targets that bsd.pkg.mk uses
internally for information-gathering, e.g. show-var, run-depends-list.
Instead of saving the values, we now just don't compute them during phases
of the build that don't care about the dependency information, e.g. when
not in extract, install, or package.
create _BLNK_ADD_TO.<depmethod> for each of depencdency methods above from
the BUILDLINK_DEPEND.<pkg> and BUILDLINK_RECOMMENDED.<pkg> lists and save
the created values so they don't need to constantly be recomputed.
enforce that using PHASES_AFTER_BUILDLINK.
Also, transform the physical path to ${WRKDIR} into the value ${WRKDIR} in
the wrapper scripts. This allows ${WRKDIR} to be a path that traverses a
symlink. In particular, it allows users to set WRKOBJDIR to point to a
symlink.
wrapper script will transform, then output the transformed command.
Prefix the original command with [*] and the transformed command with <.>
to ease scanning of .work.log.
an extra list of paths denoting entire directory trees that will be
unchanged by the wrapper scripts in options passed to the toolchain.
BUILDLINK_PASSTHRU_RPATHDIRS is the same as BUILDLINK_PASSTHRU_DIRS
but the the listed paths are only unchanged if used in an rpath option.
* Garbage-collect _BLNK_BUILTIN_DIRS, which is superseded by
_BLNK_PASSTHRU_DIRS.
* Ensure that the correct set of directories is passed to the linker
for the runtime library search path in the pkgviews case.
* Allow -I/usr/include/* to be unchanged by the wrapper scripts. This
allows building LKMs in pkgsrc, which need -I/usr/include/sys, using
the buildlink3 wrapper scripts.
instances of directory paths to mangle. We now check that the path
is either a word by itself, or else part of likely compiler/linker
options (-[ILR]).
* Add a new "submangle" command that does the same thing as mangle but
restricts itself to only the directory tree below the named src
directory.
fine-grained distinction between required versions of pre-requisites
(DEPENDS) and versions that are recommended for security or library ABI
consistency reasons (RECOMMENDED).
The contents of ${RECOMMENDED} are added to DEPENDS unless
IGNORE_RECOMMENDED is set to YES, in which case a warning will be printed
and IGNORE_RECOMMENDED will be added to BUILD_DEFS.
Add a corresponding BUILDLINK_RECOMMENDED.<pkg> variable for use with
buildlink2 and buildlink3.
they needed to be. Now, when we're emitting untransform rules, we:
(1) change everything back from ${BUILDLINK_DIR} and ${BUILDLINK_X11_DIR}
back into ${LOCALBASE} and ${X11BASE},
(2) protect ${LOCALBASE} and ${X11BASE} from changes,
(3) nuke all other compiler/linker options that have absolute paths that
we haven't blessed, and
(4) unmangle all of the protected directory names back into the right
names.
This should correctly fix the problem where "gtk-config --cflags" didn't
emit any directories for glib headers.
lists values other "include" or "lib", then protect those directories from
being eaten by the wrapper scripts. This allows -I/usr/include/krb5 to be
passed safely through to the real compiler when heimdal/buildlink3.mk is
included.
untransform cases. This should fix the problem noted on tech-pkg@:
"Re: graphics/gdk-pixbuf can't find <gdk/gdk.h> build problem" where the
CFLAGS for glib were being eaten by the unbuildlink step.
in when creating this file based on the one in buildlink2. This should
fix the problem noted on tech-pkg@: "Re: graphics/gdk-pixbuf can't find
<gdk/gdk.h> build problem" where the CFLAGS for glib were being eaten by
the unbuildlink step.
* Don't add any dependencies (via BUILDLINK_DEPENDS) unless
buildlink3.mk files add them. This fixes case where the software
existed both in the base system and in /usr/pkg, we used only the
built-in software, but we still recorded a dependency on the one in
/usr/pkg.
* Re-structure the code that populates ${BUILDLINK_DIR} so that we
don't bump into ARG_MAX limits in the shell. This should fix the
problem present in the buildlink2 framework noted in:
http://mail-index.netbsd.org/tech-pkg/2004/01/03/0005.html
CHANGES:
* Define a new yes/no variable BUILDLINK_USE_BUILTIN.<pkg> that
determines if we should use the built-in software or not. This
should probably replace the various USE_NCURSES, USE_GNU_READLINE,
USE_GNU_GETTEXT, etc. variables with something whose naming is a
bit more consistent and is integrated directly into the buildlink3
framework.
* Garbage-collect "$$pkg_prefix", which was used exclusively in
BUILDLINK_FILES_CMD.<pkg>. It no longer exists in the
buildlink3/pkgviews world. Packages _should_ _no_ _longer_
directly set the PREFIX variable in the package Makefile. As a
consequence, the various Java VM packages will need some changes
when they're converted to use buildlink3.
Prepending caused everything in ${BUILDLINK_DIR} to be found first, which
was bad when you built something like MesaLib where the X11R6 headers
conflict with the ones provided in the source.
need to protect the full path after "-o" from being transformed from
"/srcdir/shlib" to "-L/srcdir -lshlib". This fixes building
graphics/freetype2, which uses lots of full paths to sources and objects.
Changes include supporting XFree86-4.3.99.14 aka XFree86-current.
Added some new library versions and some freetype2 include files.
And bump the required version number in the bsd.buildlink mk's.
know read the arguments by first placing them in a buffer and taking
the argument in the first non-empty buffer as the argument to process.
The buffer is there to allow "splitting" an argument into multiple
arguments (currently up to five arguments), e.g. "-Wl,-R/path1:/path2"
is split into "-Wl,-R/path1" and "-Wl,-R/path2". Each split argument
is placed into a buffer. Using a buffer lets us read and process all
of the arguments in a single pass despite "pushing" more arguments
onto the front of the argument array.
the final installed location for the named shared library, and we
need to protect the full path from "/path/shlib" -> "-L/path -lshlib"
transformation.
their own files: buildcmd and quotearg, which are used to build up the
command line and to quote arguments. Also add the ability to skip
processing the next few arguments and add them directly to the command
line. Now, either the marshall script or the cache scripts can
request skipping the N arguments by setting skipargs=N.
strong cup of coffee. This now works the way it was intended: the
buildlink3.mk file sets a variable that can be checked within itself to
see whether it's already been included or not.
non-recursive dependencies. We now use the check:
.if !defined(BUILDLINK_PACKAGES) || empty(BUILDLINK_PACKAGES:Mfoo)
...
.endif
to replace the FOO_BUILDLINK3_MK guards.
BUILDLINK_{DEPENDS,PACKAGES} and use them throughout bsd.buildlink3.mk.
A lot of processing iterates over these variables and assumes that there
are no repeated items in those lists.
buildlink2/buildlink3 world. We "buildlink" libtool archives into
${BUILDLINK_DIR} and instruct libtool to find those *.la files before
any other ones.
we've already seen:
-[DILR]*|-Wl,-R*|-Wl,-*,/*
These are all only useful the first time we see them. All other
instances are redundant.
-l*
Extra libraries are suppressed if they're repeated, e.g.,
"-lm -lm -lm -lX11 -lX11 -lm -lm" -> "-lm -lX11 -lm".
The screen output is still likely to be very verbose, but you can check
in work/.work.log to see the actual commands executed.
do it for rpath specifications, e.g. -Wl,-R/dir, -Wl,-rpath,/dir, etc.
This lets the depot directory for a package, in addition to the usual
/usr/pkg/lib, to be added to the rpath of a program or shared library
of an "overwrite" package. Now, if the package instance in the
default view is forcibly removed, then shared library references will
still resolve to the existing shared libraries in the depot directory.
In the following example, I've built jpeg as a pkgviews package, and
tiff as an "overwrite" package:
% ldd /usr/pkg/lib/libtiff.so
/usr/pkg/lib/libtiff.so:
-ljpeg.62 => /usr/pkg/lib/libjpeg.so.62
-lz.0 => /usr/lib/libz.so.0
-lm.0 => /usr/lib/libm387.so.0
-lm.0 => /usr/lib/libm.so.0
% pkg_delete -f jpeg-6b
pkg_delete: package `jpeg-6b' is required by other packages:
tiff-3.5.7nb1
% ldd /usr/pkg/lib/libtiff.so
/usr/pkg/lib/libtiff.so:
-ljpeg.62 => /usr/pkg/packages/jpeg-6b/lib/libjpeg.so.62
-lz.0 => /usr/lib/libz.so.0
-lm.0 => /usr/lib/libm387.so.0
-lm.0 => /usr/lib/libm.so.0
The benefit here is that if the jpeg package is updated and also has
a bump in the major number of the shared lib, e.g. libjpeg.so.63.0,
then you can remove the old jpeg instance from the default view and
add the new jpeg package into the default view, and
/usr/pkg/lib/libtiff.so will _still_ resolve its libjpeg.so.62
reference.
Welcome to the power of Package Views!
automatically added to CFLAGS and CXXFLAGS. Note that -D... and -I...
settings should go into BUILDLINK_CPPFLAGS.<pkg> instead. BUILDLINK_CFLAGS
is reserved for stuff like "-pthread" or other compiler-specific flags.
Also note why we add BUILDLINK_CPPFLAGS.<pkg> to both CFLAGS and CXXFLAGS
(because a lot of software just uses CFLAGS and ignores any CPPFLAGS value
that we pass to it).
