Julio M. Merino Vidal writes: 

> On 11/4/06, diro@nixsys.bz <diro@nixsys.bz> wrote:
>> >> On Fri, Nov 03, 2006 at 07:51:02PM +0000, diro@nixsys.bz wrote:
>> >> Is there an easy way to specify CONFIGURE_ARGS for different packages 
>> in
>> >> mk.conf? 
>> 
>> > You shouldn't do that, but it can be done by using ${.CURDIR}. 
>> 
>> > Joerg 
>> 
>> There are options i need to feed the mail/sqwebmail build, which aren't
>> covered in its PKG_OPTIONS. Rather then edit the Makefile, update via CVS
>> every quarter and deal with the mangled Makefile, i've found it easier to
>> just remove the whole tree and replace it anew each quarter. Instead of
>> re-editing the Makefile for certain packages, i was hoping there's an 
>> easier
>> way to feed it specific options. 
>> 
>> 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.

Indeed. :-\ However, there are some things which are rather simple settings 
in the package. 

> On the other hand, the existing PKG_OPTIONS have (supposedly) been
> tested and the package is properly made to honor them (registering the
> correct files, keeping track of dependencies appropriately, etc.). 
> 
> -- 
> Julio M. Merino Vidal <jmmv84@gmail.com>
> The Julipedia - http://julipedia.blogspot.com/
 

Even with PKG_OPTIONS, though, take sqwebmail again as an example. Things 
like: 

 --with-maxargsize =n
 --with-maxformargsize=n 

Which aren't crazy dependencies or correct files, just something that limits 
attachment sizes, how would that be easily specified with PKG_OPTIONS? I 
believe the point of PKG_OPTIONS was to get away from having a lot of 
variables specific to a certain package set in the environment or mk.conf, 
however, what is the ease of this structure now or rather the preferred 
method of doing so? 

!tr