Re: multi-variant packages and bulk builds

[Aleksey Cheusov <cheusov%tut.by@localhost>]

 >> 1) category/package/Makefile:
 >>    ...
 >>    PKGNAME=general-package-name${OPTIONS_SUFX}-version
 >>    ...
 >>
 >> 2) somewhere in pkgsrc .mk files
 >>    .if defined(GENERATE_ALL_OPTIONS_PKGS) && defined(PKG_SUPPORTED_OPTIONS)
 >>        VARIANTS+= ...
 >>        # VARIANTS should look like OPTIONS.name1=0,1 OPTIONS.name2=0,1 ...
 >>        # 0 means "feature is disabled", 1 - "enabled"
 >>    .endif
 >>
 >> 3) .for opt in ${PKG_SUPPORTED_OPTIONS}
 >>       .if ${OPTIONS.${opt}} = 1
 >>           OPTIONS_SUFX += -${f} # string concatenation here, not +=
 >>       .endif
 >>    .endfor
 >>

> How do you plan to organize the resulting binary packages for all
> possible combinations of options?

When you say "to organize" you mean dependancies between
packages having options?

First of all, all options should be splitted into two categories.

Category 1: options with GLOBALLY THE SAME SEMANTICS,
   that is option with the same semantics for ALL packages.

   For example, disabling -x11 option should ALWAYS mean
   "no X support at all", and disabling -ssl option should ALWAYS
   mean "no ssl support at all" for ALL packages.

Category 2: options meaning different things for different packages.
   Solutions:
    a) avoid options of this category at all. That is, all package-specific
       options MUST have a uniq name.
    b) mark such options somehow and use this marker.

After this, I presume dependancies can be set relatively easily.
If, say, package A depends on package B and both they have option, e.g. x11,
then binary package A-version%x11.tgz depends on  B-version%x11.tgz
and package A-version%nox11.tgz depends on B-version%nox11.tgz.
In this example I assume that option x11 is of "category 1".
Here % is a char-separator between "old plain PKGNAME" and options part.

-- 
Best regards, Aleksey Cheusov.