On Wed, May 13, 2020 at 10:14 AM Peter Kjellerstedt <peter.kjellerst...@axis.com> wrote: > > > -----Original Message----- > > From: Andre McCurdy <armccu...@gmail.com> > > Sent: den 13 maj 2020 00:20 > > To: Peter Kjellerstedt <peter.kjellerst...@axis.com> > > Cc: OE Core mailing list <openembedded-core@lists.openembedded.org> > > Subject: Re: [OE-core] [PATCH] file: Remove unneccessary override of > > PACKAGECONFIG for native > > > > On Tue, May 12, 2020 at 2:43 PM Peter Kjellerstedt > > <peter.kjellerst...@axis.com> wrote: > > > > > > There is no reason to set PACKAGECONFIG_class-native to the same value > > > as the default PACKAGECONFIG. > > > > End users often don't know how to safely change PACKAGECONFIG from a > > .bbappend and might try PACKAGECONFIG += "foo" or PACKAGECONFIG_append > > = " foo" without realising that it could affect more than just the > > target build. > > > > Have an explicit PACKAGECONFIG_class-native keeps the native config > > stable for users who haven't yet learning through experience that the > > safe way to change PACKAGECONFIG is PACKAGECONFIG_append_class-target > > = " foo". > > > > So although this PACKAGECONFIG_class-native may seem redundant to the > > experts, it helps make OE more robust for regular users. > > I have to disagree with this. Having just PACKAGECONFIG ??= "zlib" > makes for a more consistent behavior between the different classes.
I don't see why a consistent configuration between the different classes is a goal. We should instead try to keep them independent so that changes to one don't accidentally affect the others. The configuration for the target is determined by the functionality required in the final image (ie something determined by the user) and the configuration for native and nativesdk is mostly determined by the requirements of the build environment. The requirements for the build environment are fairly static and not something a typical user would want to mess with. > E.g., if someone would add a .bbappend with PACKAGECONFIG = "zlib > bz2", with the current recipe the behavior would be different when > building file and nativesdk-file compared to file-native (or actually > file-replacement-native as file-native is in ASSUME_PROVIDED). With > only the default PACKAGECONFIG, the result would be the same also > for file-native. Having an over-ride for native but not considering nativesdk is certainly an issue which seems to affect many recipes in oe-core. But the fix should be adding an over-ride for nativesdk rather than removing the over-ride for native. (I don't know why this problem doesn't come up more often. Perhaps because while there are users who like to change PACKAGECONFIG values and users who build for nativesdk the overlap between them is actually quite small?). > A quick grep through OE-Core also seems to agree with me. There are > a couple of other recipes that sets PACKAGECONFIG_class- defaults, > but then it's due to the default for, e.g., native being different > from target. The only other recipe I could find that sets multiple > identical PACKAGECONFIG defaults is openssl. Yes. Unfortunately making recipes robust for users who want to change PACKAGECONFIG values doesn't seem to be a high priority for oe-core. Why else would default PACKAGECONFIG values be assigned with ??= instead of ?= other than as a trap for new users?
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138234): https://lists.openembedded.org/g/openembedded-core/message/138234 Mute This Topic: https://lists.openembedded.org/mt/74169167/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
