This changes the buildlink3.mk files to use an include guard for the
recursive include. The use of BUILDLINK_DEPTH, BUILDLINK_DEPENDS,
BUILDLINK_PACKAGES and BUILDLINK_ORDER is handled by a single new
variable BUILDLINK_TREE. Each buildlink3.mk file adds a pair of
enter/exit marker, which can be used to reconstruct the tree and
to determine first level includes. Avoiding := for large variables
(BUILDLINK_ORDER) speeds up parse time as += has linear complexity.
The include guard reduces system time by avoiding reading files over and
over again. For complex packages this reduces both %user and %sys time to
half of the former time.
X.Org found in NetBSD-current.
Thanks a lot to all who helped, especially Matthias Scheler who did
repeated tests on Mac OS X and older versions of NetBSD to make sure the
support for those platforms wouldn't be broken (or at least, not fatally,
as I would still expect a few hiccups here and there, because there is
only so much one can test in such limited time).
On the infrastructure side, this branch brings pkgconfig-builtin.mk, in
order to write very easily new builtin.mk files. It can actually handle
more than just pkgconfig files, but it will provide a version if it finds
such a file. x11.builtin.mk has also been made more useful and now all
existing (and future!) native-X11-related builtin.mk files should include
it.
the full requirement rather than just the package name. This message
should never be seen (after all, the package we need is supposed to
*get* installed) but sometimes if things are screwed up in one way or
another it does show up. Since often what's wrong is that the package
that's installed is the wrong version, not that it's missing entirely,
this way the error message makes a lot more sense.
E.g. http://mail-index.netbsd.org/tech-pkg/2008/06/12/msg001126.html et seq.
ok dillo@
in bsd.buildlink3.mk was broken with pkg_install-20080309 was it
returned a relative path. It would have failed before e.g. with symbolic
links in the path. pkg_info -E is simpler and was added exactly for this
purpose. Fixes PR 38213 and PR 38211.
- USE_CROSS_COMPILATION activates it, CROSS_DESTDIR specifies root of
the target filesystem
- derive _CROSS_DESTDIR from CROSS_DESTDIR or MAKEOBJDIR
- buildlink3.mk prefixes the files to symlink with _CROSS_DESTDIR
- compiler/gcc.mk knows about the target prefix (e.g. i386--netbsdelf)
- PKG_DBDIR is prefixed with _CROSS_DESTDIR
- package-install and bin-install are not called with su
- install and strip are redirected to the tool version
- links for the target specific ar, as, ld, nm, objdump, ranlib and
strip are added
- compiler wrapper detect if linking is requested or not
- special command sinks for CPP and CC/CXX add the cross-compile magic:
- modify include dirs to get the target /usr/include
- modify linker dirs and runpath to use target /usr/lib at link time,
but keep correct rpath entries
Supported-by: Google SoC 2007
Basic tests by he@ on Sparc. Review from jlam@.
We can't use our own imake to check for builtin packages so disable the
check and always report that no builtin implementation exists.
No objections on tech-pkg@
clear that these variables are completely unrelated to
BUILDLINK_TRANSFORM.
Added a legacy check that catches appearances of BUILDLINK_TRANSFORM.*.
XXX: Where should incompatible changes in pkgsrc be documented?
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@
