Re: [OE-core] any *compelling* reasons to whitelist env vars for an OE build?
Just a quick note that you *can* script config file alterations without having to alter files that may be under source control, that's what auto.conf is for :) On Thu, Mar 25, 2021 at 7:51 AM Robert P. J. Day wrote: > On Thu, 25 Mar 2021, Mike Looijmans wrote: > > > I for one use a whitelist env vars daily, both hobby and work. > > > > We tend to build for multiple machines, so in general we'd have > > something like this running on the build server: > > > > for machine in mach1 mach2 mach3 mach4 ... mach40 > > do > >MACHINE=$machine bitbake image1 image2 image3 > > done > > > > Being able to pass the MACHINE through the environment is a big win. We > could > > alter a config file in the shell script, but that would change a file > that > > we'd want under version control, and I really don't like it when builds > change > > files under version control. > > > > (The "40" machines is not exaggerated, I'm really involved in projects > that > > build for that many targets) > > > > Come to think of it, MACHINE is the one and only environment we ever > pass to > > bitbake. > > > > For release/test/production/debug/... etcetera I tend to use a different > > image, so you'd see: > > > > MACHINE=mach1 bitbake interesting-image interesting-image-dev > > you and mark are right, i was being a bit too draconian -- being > able to select MACHINE and DISTRO on the bitbake invocation line are > obvious benefits. > > just to refresh my memory, what is it that identifies the env vars > that are by default passed through without any need for extra > whitelisting? is that BB_ENV_EXTRAWHITE? i recall that contains > MACHINE and DISTRO already, so that might be all i care about. > > rday > > > > -- Christopher Larson kergoth at gmail dot com Founder - BitBake, OpenEmbedded, OpenZaurus Senior Software Engineer, Mentor Graphics -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149938): https://lists.openembedded.org/g/openembedded-core/message/149938 Mute This Topic: https://lists.openembedded.org/mt/81603196/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] any *compelling* reasons to whitelist env vars for an OE build?
On Thu, 25 Mar 2021, Mike Looijmans wrote: > I for one use a whitelist env vars daily, both hobby and work. > > We tend to build for multiple machines, so in general we'd have > something like this running on the build server: > > for machine in mach1 mach2 mach3 mach4 ... mach40 > do >MACHINE=$machine bitbake image1 image2 image3 > done > > Being able to pass the MACHINE through the environment is a big win. We could > alter a config file in the shell script, but that would change a file that > we'd want under version control, and I really don't like it when builds change > files under version control. > > (The "40" machines is not exaggerated, I'm really involved in projects that > build for that many targets) > > Come to think of it, MACHINE is the one and only environment we ever pass to > bitbake. > > For release/test/production/debug/... etcetera I tend to use a different > image, so you'd see: > > MACHINE=mach1 bitbake interesting-image interesting-image-dev you and mark are right, i was being a bit too draconian -- being able to select MACHINE and DISTRO on the bitbake invocation line are obvious benefits. just to refresh my memory, what is it that identifies the env vars that are by default passed through without any need for extra whitelisting? is that BB_ENV_EXTRAWHITE? i recall that contains MACHINE and DISTRO already, so that might be all i care about. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149932): https://lists.openembedded.org/g/openembedded-core/message/149932 Mute This Topic: https://lists.openembedded.org/mt/81603196/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] any *compelling* reasons to whitelist env vars for an OE build?
I for one use a whitelist env vars daily, both hobby and work. We tend to build for multiple machines, so in general we'd have something like this running on the build server: for machine in mach1 mach2 mach3 mach4 ... mach40 do MACHINE=$machine bitbake image1 image2 image3 done Being able to pass the MACHINE through the environment is a big win. We could alter a config file in the shell script, but that would change a file that we'd want under version control, and I really don't like it when builds change files under version control. (The "40" machines is not exaggerated, I'm really involved in projects that build for that many targets) Come to think of it, MACHINE is the one and only environment we ever pass to bitbake. For release/test/production/debug/... etcetera I tend to use a different image, so you'd see: MACHINE=mach1 bitbake interesting-image interesting-image-dev So "interesting-image" would be the product, while the "dev" version would apply debug tweaks that make the rootfs writeable and enable the serial console for login and things like that. Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Products B.V. Materiaalweg 4, 5681 RJ Best The Netherlands T: +31 (0) 499 33 69 69 E: mike.looijm...@topicproducts.com W: www.topic.nl Please consider the environment before printing this e-mail On 25-03-2021 15:08, Robert P. J. Day via lists.openembedded.org wrote: kind of a philosophical question, but i'm having a discussion with some new colleagues about how to customize an OE (actually, wind river linux) build, and these colleagues have, until now, used (whitelisted) environment variables to pass info to the build, that info being used to specify things like a development versus manufacturing build, and so on. i suggested that i didn't think there was any really persuasive reasons to use environment variables this way, as there are more than enough configuration files to customize a build. i mentioned things like: * machine config files * distro config files * defining packagegroup files * defining image files and on and on and on. my point was that there are more than enough ways to support all the customization you might need, that taking advantage of shell environment variables strikes me as unnecessarily messy and, for that matter, dangerous if you forget so set the environment. thoughts? am i out of line in advising them to use what OE offers them, and not extract stuff from the environment? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149931): https://lists.openembedded.org/g/openembedded-core/message/149931 Mute This Topic: https://lists.openembedded.org/mt/81603196/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] any *compelling* reasons to whitelist env vars for an OE build?
On 3/25/21 9:08 AM, Robert P. J. Day wrote: > > kind of a philosophical question, but i'm having a discussion with > some new colleagues about how to customize an OE (actually, wind river > linux) build, and these colleagues have, until now, used (whitelisted) > environment variables to pass info to the build, that info being used > to specify things like a development versus manufacturing build, and > so on. > > i suggested that i didn't think there was any really persuasive > reasons to use environment variables this way, as there are more than > enough configuration files to customize a build. i mentioned things > like: > > * machine config files > * distro config files > * defining packagegroup files > * defining image files > > and on and on and on. > > my point was that there are more than enough ways to support all the > customization you might need, that taking advantage of shell > environment variables strikes me as unnecessarily messy and, for that > matter, dangerous if you forget so set the environment. > > thoughts? am i out of line in advising them to use what OE offers > them, and not extract stuff from the environment? I _always_ do builds like: MACHINE=zynqmp-generic DISTRO=petalinux bitbake core-image-minimal I don't want to have to update any configuration files to pass basic values into the system. This is also used heavily on my build systems so we can have a common configuration for all builds, but built across a wide breadth of components. I also occasionally use BB_ENV_EXTRAWHITE to add additional variables I might want to override. For instance, sometimes I want TMPDIR to go to a different location, instead of having to modify local.conf (and then remember to put it back the way it was) I can just add to the EXTRAWHITE, and call passing in TMPDIR. --Mark > rday > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149928): https://lists.openembedded.org/g/openembedded-core/message/149928 Mute This Topic: https://lists.openembedded.org/mt/81603196/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] any *compelling* reasons to whitelist env vars for an OE build?
kind of a philosophical question, but i'm having a discussion with some new colleagues about how to customize an OE (actually, wind river linux) build, and these colleagues have, until now, used (whitelisted) environment variables to pass info to the build, that info being used to specify things like a development versus manufacturing build, and so on. i suggested that i didn't think there was any really persuasive reasons to use environment variables this way, as there are more than enough configuration files to customize a build. i mentioned things like: * machine config files * distro config files * defining packagegroup files * defining image files and on and on and on. my point was that there are more than enough ways to support all the customization you might need, that taking advantage of shell environment variables strikes me as unnecessarily messy and, for that matter, dangerous if you forget so set the environment. thoughts? am i out of line in advising them to use what OE offers them, and not extract stuff from the environment? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149927): https://lists.openembedded.org/g/openembedded-core/message/149927 Mute This Topic: https://lists.openembedded.org/mt/81603196/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
