[LEDE-DEV] What's the purpose / gain from using VARIANT?
Sergey Ryazanov
ryazanov.s.a at gmail.com
Wed Dec 7 14:41:13 PST 2016
On Wed, Dec 7, 2016 at 10:52 PM, Rafał Miłecki <zajec5 at gmail.com> wrote:
> On 12/07/2016 08:36 PM, Sergey Ryazanov wrote:
>> On Wed, Dec 7, 2016 at 10:10 PM, Rafał Miłecki <zajec5 at gmail.com> wrote:
>>> I'm aware some packages (e.g. upstream-ssl, hostapd, dnsmasq) use
>>> VARIANT.
>>>
>>> I don't really understand the gain of this. How does it differ from
>>> specifying separated packages?
>>> I'm looking at package/libs/ustream-ssl/Makefile and I don't see much
>>> code saving from using this VARIANT variable/feature.
>>> Looking at package/system/opkg/Makefile I can see BUILD_VARIANT is
>>> used for more specific CONFIGURE_ARGS. Is that where VARIANTS gets
>>> really helpful?
>>> Maybe I'm missing some real gain/value?
>>
>>
>> IMHO VARIANT usage helps consolidate patches in single place. E.g. if
>> you would like change some common code in hostapd then just create a
>> new patch and VARIANT build two packages (hostapd/wpa_supplicant)
>> from updated code. Without VARIANT you should duplicate your changes
>> (patch) in multiple places and keep them synchronized. So the gain is
>> simple: reducing of unproductive work.
>
> I don't think sharing patches has anything to do with VARIANT. As long as
> you
> define packages in one Makefile they are going to share source (and so
> patches).
>
> I did a trivial test with iw package. I created iw2 and compiled it using
> make package/network/utils/iw/install V=s
>
> I got one source directory:
> build_dir/target-*/iw-4.9
> and two package directories:
> build_dir/target-arm_cortex-a9_musl-1.1.15_eabi/iw-4.9/ipkg-*/iw
> build_dir/target-arm_cortex-a9_musl-1.1.15_eabi/iw-4.9/ipkg-*/iw2
>
Exactly. You got single build directory with the same sources the same
objects and finally the same binaries. But not different output
binaries from the same sources.
Another one good example of VARIANT usage is OpenVPN package(s).
--
Sergey
More information about the Lede-dev
mailing list