On 8 December 2016 at 02:00, Florian Fainelli <f.faine...@gmail.com> wrote: > On 12/07/2016 11:52 AM, Rafał Miłecki wrote: >> On 12/07/2016 08:36 PM, Sergey Ryazanov wrote: >>> On Wed, Dec 7, 2016 at 10:10 PM, Rafał Miłecki <zaj...@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). > > IMHO, this is more about sharing the build recipe more than anything > else. Usually building from one variant to another is just a matter of > tuning a bunch of build configuration parameters, but the bulk of how to > build a package remains the same.
Thanks for your help, it makes more sense now. My summary: Packages defined in a single Makefile share PKG_* variables and Build/* defines (steps). If packaged software doesn't generate multiple files you want to put into separated packages AND you need to adjust Build/* defines (steps) THEN having BUILD_VARIANT gets handy. So VARIANT should be used when having: 1) Shared Build/Prepare 2) Shared Build/Compile 3) Separated Package/foo/install isn't enough. -- Rafał _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev