| Message ID | e0adfdd7-280e-315c-c7f1-206e38b3bdf8@gmail.com |
|---|---|
| State | Not Applicable |
| Headers | show |
On Wed, Dec 7, 2016 at 10:52 PM, Rafał Miłecki <zajec5@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@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).
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 <zajec5@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.
On 8 December 2016 at 02:00, Florian Fainelli <f.fainelli@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 <zajec5@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.
diff --git a/package/network/utils/iw/Makefile b/package/network/utils/iw/Makefile index f84978f..7674056 100644 --- a/package/network/utils/iw/Makefile +++ b/package/network/utils/iw/Makefile @@ -28,6 +28,11 @@ define Package/iw DEPENDS:= +libnl-tiny endef +define Package/iw2 + $(Package/iw) + TITLE:=cfg80211 interface configuration utility 2 +endef + define Build/Configure echo "const char iw_version[] = \"$(PKG_VERSION)\";" > $(PKG_BUILD_DIR)/version.c rm -f $(PKG_BUILD_DIR)/version.sh @@ -54,4 +59,9 @@ define Package/iw/install $(INSTALL_BIN) $(PKG_BUILD_DIR)/iw $(1)/usr/sbin/ endef +define Package/iw2/install + $(Package/iw/install) +endef + $(eval $(call BuildPackage,iw)) +$(eval $(call BuildPackage,iw2))