Leonardo Taccari <leot%NetBSD.org@localhost> writes:
> Hello Greg,
>
> Greg Troxel writes:
>> Is enough of dtrace always built with NetBSD for using dtrace to make
>> sense (vs being an option)? Generally, pkgsrc tries to avoid
>> compile-time detection in favor of requiring features or hiding them
>> (via bl3).
> You're right, I think that a dtrace option (like lang/perl5) is better,
> conditionally added to PKG_SUPPORTED_OPTIONS or PKG_SUGGESTED_OPTIONS
> depending on ${OPSYS}.
I built ruby200-base on netbsd-7 amd64 (with no MK options), and it
built fine.
So my impression is that during the freeze, no changes are needed.
>> But, we don't really have a good way to deal with things that are
>> optional in the base system. It seems with dtrace there are some MK
>> variables to set in the build, rather than it being standard.
Historically, headers were always installed for optional kernel
features, so that code would compile and then work or not at runtime.
But DTRace seems big enough that we aren't always building the userland
parts.
>> So I wonder if you are building on a stock netbsd-7 machine, or if
>> you've enabled dtrace specifically.
> Yes, I'm running NetBSD-current built with MKDTRACE=yes and MKCTF=yes in
> order to fully enable DTrace.
So there are two things to fix:
figure out and fix DTrace support in your environment
decide how to deal with optional DTrace support in packages.
Probably adding it to PKG_SUPPORTED_OPTIONS on systems where it might
work is in order. Alternatively there should probably be a
mk/dtrace.mk that somehow deals with this, turning it into a
pseudo-package, so that each program doesn't have repeated logic.
Attachment:
signature.asc
Description: PGP signature