Subject: Re: per package CONFIGURE_ARGS in mk.conf
To: None <tech-pkg@NetBSD.org>
From: Christian Biere <firstname.lastname@example.org>
Date: 11/05/2006 15:06:49
Bernd Ernesti wrote:
> On Sat, Nov 04, 2006 at 08:03:10PM +0100, Julio M. Merino Vidal wrote:
> > On 11/4/06, email@example.com <firstname.lastname@example.org> wrote:
> > >What would be so horrible about having something like
> > >CONFIGURE_ARGS.package_name? This would save having a lot of PKG_OPTIONS
> > >settings for the many configure args that can be used to tweak specific
> > >packages.
> > That many configure options have lots of side effects with respect to
> > installed files, available features, program behavior, etc.
> > Supporting such a setup would result in lots of random problems and
> > broken packages all around.
> IMHO it is not that this will be used for binary packages, but they
> are needed if you want to build a package with a specific option.
> I allways have to modify my /etc/mk.conf when i build squid so I get
> the correct options which are not handeld by PKG_OPTIONS:
> #CONFIGURE_ARGS+= --enable-useragent_log
> This is not only for CONFIGURE_ARGS but also for a package specific
I think I'd prefer using something like
CONFIGURE_ARGS += ...
I just tried it with wm/jwm (s/example/jwm/) as a test and it seems to
Maybe I'd even put each of those into a dedicated file e.g., I include
/usr/pkg/etc/mk.conf conditionally from /etc/mk.conf. In this case
mainly because so that I don't have to mount / or /etc writable but
in general it's also more readable. So if there's a variable that
can be used to check for the current package, everybody would be happy
I believe. It shouldn't be based on hack which is likely to break as
Of course, in many cases adding a switch or the like will leave you
with warnings about missing files or similar. So you'd have to write
or extend options.mk for the package in question especially if you
want to get rid of some near-pointless dependencies.