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

[Edgar Fuß <ef%math.uni-bonn.de@localhost>]

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?