Re: Package Option naming: support to build with vs. default to build in

[Thomas Klausner <wiz%NetBSD.org@localhost>]

On Thu, Aug 10, 2017 at 02:19:56PM +0200, Edgar Fuß wrote:
> I'm working on adding options to print/cups-filters.
> 
> The PDF-to-PS-filter (libexec/cups/filters/pdftops) can use different 
> PDF-to-PS renderers (acroread, ghostscript, poppler's pdftops, 
> poppler/cairo's pdftocairo), and I would like to add a package option 
> which of those to make available. (CUPS then selects via a per-printer- 
> or per-job-option which one to use.) Additionally, when building the package, 
> you chose the default renderer to use in absence of the CUPS option (there's 
> no config file for cups-filters).
> 
> So, on the one hand, I would like to use "pdftops" as an option value name 
> meaning "build the package with support for using poppler as a 
> PDF-to-PS-renderer" (i.e., depend on poppler-utils, etc.), on the other hand, 
> I would like to use "pdftops" meaning "use poppler as a default".
> What's the standard way to handle this (support to build a package with vs. 
> default to configure into the built program)? I could think of option value 
> names like cups-pdftops-renderer-pdftops and 
> cups-pdftops-renderer-default-pdftops, but who wants to type or read that?
> 
> Any suggestions for the option names itself? 
> cups-pdftops-renderers/cups-pdftops-renderer-default? 
> pdftops-renderers/pdftops-renderer?

Can you enable all renderers by default, and just make an option for
the default? Then users could install an alternate renderer separately
at a later time.
 Thomas