Sorry for the delay in replying to this. There are multiple reasons, I partly wanted to try and give time for others to experiment with this. I'm all too aware that when something merges, there will be a ton of "complaints" about choices that were made. I'd hoped by giving people time, they might be able to experiment with it but that clearly (and sadly) isn't happening. We'll therefore have to make do with our best guesses and instinct.
My first comment coming back to this is that I don't think we should default to $HOME/builds as that is hard to discover (I got there via an error message). I think we should error saying the user hadn't configured a default and tell them how to, or to use --build-dir. That implies the tool will need some user config file, but I suspect we're going to need that anyway. I'd also note that: "bitbake-setup init poky-alex --build-dir /xxx/poky-alex" crashes (i.e. when the dir == config name). On Wed, 2024-06-12 at 10:46 +0200, Alexander Kanavin wrote: > On Mon, 10 Jun 2024 at 13:22, Richard Purdie > <[email protected]> wrote: > > From the init command, it isn't clear what build.sh is for. I think it > > should also mention the traditional build env file too, make it clear > > where that is. > > The printed note is: "Run path/to/build.sh to build using this configuration." > > Can you suggest a better wording (I have ideas, but want to hear how > you would put it)? I think the init process needs to tell the user what it is doing. Part of our aim here is to shortcut things for the user but to also give them the option of learning how/what to do for themselves. At the moment you get a load of git clone output but not a real idea of *what* it does. I'm thinking improving the output to something like: **** Cloning OE-Core and layers **** Cloning XXX to /dest/path [git clone output] Cloning XXX2 to /dest/path2 [git clone output] **** Configuring build defaults **** Adding layer XXXX Setting up configuration in /dest/path/local.conf **** Summary **** Metadata setup in directory: XXX Build directory configured as: YYY Shortcut environment: ". /xxx/init-build-env" Expanded environment setup: ". /xxx/yyy/oe-init-build-env <builddir>" Run path/to/build.sh to execute the default build targets for this configuration or source the environment to run builds from the commandline. We can always have a quiet option for people who don't want some of this but I think it should default to telling people what it is doing and in particular, *where* on disk it is putting things which I think is my real aim here - let people navigate. > > I struggled to find the --build-dir option to init, I tried to specify > > a direction as the next parameter but that has to be named. > > I wanted to keep build-dir as an optional argument, so that users > don't have to specify it and the tool will decide for them. > > This can be re-done as an optional positional argument (with > nargs='?'), but then everything else would have to be done via named > options (e.g. picking one configuration out of several - note the json > nests the config in ['bitbake-setup']['default'] to allow for multiple > entries and alternative tools in the future). I suspect leaving the option is probably the best option but we need to resolve the "default" issue as mentioned above which is perhaps my bigger concern. > > For the cloning of repos, I wondered if we should have some config file > > in HOME with a pointer to a central downloads/clone cache? The > > autobuilder will certainly need something like that. Whether we could > > use a common cache with DL_DIR remains to be seen too. > > Having a tool config on disk crossed my mind several times, but I left > it out from the prototype due to uncertainty about how writing to it > should be handled by the tool. There is a spectrum of possibilities: > from a rich 'git config'-like UI to handling it as a strict read-only > item that needs to be manually created and edited. The config could > contain other entries which are currently hardcoded in the tool and > can be overridden from command line, e.g. the location of the default > configuration repo. I think we're going to need some kind of config even to resolve the issue above so this is going to be a must have. > > I'm not sure I like the build config being moved out the way when > > updating. The tmpdir "ABI" and conf file versioning should protect us > > from the worst problems? > > Yes. The tool could back up the previous build/conf when that has to > change, but preserve everything else in build/. I like the idea of backups and leaving it around. In theory we should have compatibility. > > Also, once you're "in" a build environment, can we can bitbake-setup > > without parameters, i.e "bitbake-setup status" and "bitbake-setup > > update"? Effectively that means teaching init-build-env about the > > environment it is in so that bitbake-setup can then read the right > > config from the env. > > Yes, I'll look into it. > > > For demo purposes it might help if we could add a "poky-ng" config, > > which would be poky, but built using the config from the individual > > bitbake/core/meta-yocto/docs components. That shouldn't be too hard to > > add? > > I think so :) > > > I'll be experimenting a bit more but I wanted to give some feedback now > > I've taken a look. > > Thanks :) I can do a v2 once we settle the above points. Hopefully my above answers make sense. > Irrelevant but hopefully amusing implementation note: I've written > this with 'nano' like pretty much everything else over the past 25 > years. I'm that first person in https://xkcd.com/378/ . > > Don't be shocked, I have reasons: > - too lazy to learn a 'real' editor or install an IDE. Emacs in 1998 > made a *really* bad first impression, sorry. > - lack of 'modern' features like syntax highlighting, code folding, > cross-referencing etc. forces me to be concise and get to the point, > and don't write more code than I can fit into a single brain (or that > can be read from a github webpage and fully understood that way). > > I can fumble my way through vi when I'm forced to, but otherwise nano > all the way. I'm not shocked at all, I use mcedit a lot myself :) Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2030): https://lists.openembedded.org/g/openembedded-architecture/message/2030 Mute This Topic: https://lists.openembedded.org/mt/105860309/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
