tech-pkg archive
[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index][
Old Index]
Re: multi-variant packages and bulk builds
>> 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.
Home |
Main Index |
Thread Index |
Old Index