[38948] trunk/dports/graphics

[Ryan Schmidt]

On Aug 6, 2008, at 10:20, Guido Lorenz wrote:

> Am 06.08.2008 um 10:34 schrieb Ryan Schmidt:
>
>>> graphics/dcmtk:
>>> New port, closes #16163.
>>
>>> +variant lib description {Install libraries and include files.} {
>>> +	destroot.target-append install-lib
>>> +}
>>> +
>>> +default_variants            +lib
>>
>> Can this variant be removed? The port takes over 5 minutes to  
>> build on a dual-core Intel Mac, and additionally building the  
>> libraries only takes a few additional seconds.
>
> That's probably because the libraries are built anyway, to be  
> linked into the dcmtk applications.
>
>> Was disk space the reason the variant was created? I will grant  
>> that the installed port occupies 52MiB of disk space without  
>> libraries vs. 67MiB with. But disk space is cheap these days. I  
>> think most people won't miss the additional 15MiB.
>
> My idea was to let the user decide whether he needs the libraries  
> or not.
>
> Btw, are there any "best practice" guidelines on how much of the  
> options provided by a configure script or makefile should be made  
> available as variants in a Portfile?

Unlike a configure script, which provides options for every  
contingency, a portfile should provide just the bare minimum of  
options -- or often, no options. We want ports to build with maximal  
functionality, unless maximal functionality imposes undue hardship on  
the user*. The guideline I've used is that a variant is good if there  
is an option that some but not many people will need, and that option  
has additional dependencies, and those dependencies (or the option  
itself) take a long time to build or take a lot of disk space. But if  
it's something most users would want, or if it adds no additional  
dependency, or if the dependency it adds is small and quick, then  
forgo the variant and just build the functionality in by default.


* One example of such undue hardship can be seen here:

http://trac.macports.org/ticket/15334#comment:9


>> If the variant is to be kept, it should be changed to a no_lib  
>> variant, as in the attached patch dcmtk-no_lib.diff. However I  
>> recommend removing the variant, as in the attached patch dcmtk- 
>> always_lib.diff
>
> I'm fine with removing the variant, as it simplifies the port, and  
> the libraries are built anyway. The additional 15 MiB don't hurt,  
> either.
>
> @Ryan: Feel free to commit your dcmtk-always_lib modifications.

Done in r39039. Thanks.