bsd.port.mk(5) and actually make LLD_EMUL empty if the linker is not
ld.lld. Use a simpler variable-name-based lookup table rather than
string manipulation in a loop. Diff was worked out with espie a
couple of weeks ago.
drop a setuid bit AND not error out when they can't do stuff.
Fix the perms pre-emptively, so that aja@ can DEBUG_PACKAGES login_krb5
There are bugs to fix in binutils...!!!
- do the dir check late, so we don't create .debug dirs if not needed.
- add an emptyness check, so that we can warn if we produce an empty
debug package, and advise to tweak DEBUG_PACKAGES manually if there are
several subpackages involved
for use in regular builds too; if that is present in a port, use
${PARALLEL_MAKE_JOBS} jobs in the build, defaulting to hw.ncpuonline.
Adjust PARALLEL_BUILD=No, this originally seemed intended to be a hint
that a port could NOT handle a parallel build, but current usage is
"don't pass make -jXX because this port has its own way to handle things",
instead change this to a slightly more understandable PARALLEL_MAKE_FLAGS
variable. This defaults to -j${PARALLEL_MAKE_JOBS} but can be reset for
build system requirements as needed (java/libreoffice have their own
mechanism) and is added automatically to MAKE_FLAGS where a build uses
>1 concurrent job.
Based on a diff from / ok espie@ - the default value may want revising
as hw.ncpuonline jobs will be too many in some cases (e.g. machines with
many cores or low RAM), but committing at this stage to avoid further
out-of-tree bikeshedding. If you need to restrict to a lower number of
jobs, set e.g. PARALLEL_MAKE_JOBS=2 in /etc/mk.conf, and please provide
feedback.
Few people complained that stripped binaries are slightly
larger now than they used to be when debug packages are enabled.
My investigations show that this is because objcopy --strip-debug is
less efficient than plain strip(1) which is what we use for non-debug
packages.
Reintroducing strip(1) does not affect current debug packages behaviour
in my experience. The link to the debug symbols is still there and
egdb(1) still loads it automatically and displays all the debug info.
OK espie@
BUILD_DEPENDS and simplify (it's always defined, so no need for a "is defined"
check).
Although it's not used often there is now an external-facing library
that is part of gettext-tools so it's valid to have it listed as a LIB_DEPENDS
rather than a BUILD_DEPENDS.
_BUILDLIB_DEPENDS suggested by espie@ naddy@ as an improvement to my more
complex and less complete "check BUILD_DEPENDS and LIB_DEPENDS" which ignored
multi-packages.
- don't use $@D so that we can put two targets in there
- set a variable to add the debug package to the targets
This fixes behavior in the very specific case the normal package was already
built without DEBUG_PACKAGES and you're repackaging with DEBUG_PACKAGES set.
okay landry@
(how do you link with a lib in a package that you can't really depend
upon)
There are few enough static libs that the difference won't be that much
anyway.
okay pirofti@
them all we move them (and we can still fail if permissions are not okay)
Otherwise, we run the normal _internal-package-only again, with FETCH_PACKAGES
neutralized (as before)
This fixes the issue reported by semarie@ and kmos@
packages we build (normal/debug) and put the code back inside the actual
target instead of fragments.
Stop doing tests (shell exits as usual and trap is enough to remove temp
files).
The same logic will be used for debug_packages
not-so-good change to just using the PortsQ "cache":
- use _paths/_ports directly rather than the "ports" view and remove bogus
flavour-clearing regex subst
- open sqlports ReadOnly
