Re: [PATCH 1/2] oe-setup-build: add a tool for discovering config templates and setting up builds

[John Ogness <john.ogness@linutronix.de>]

Hi Alex,

Thanks for your work on this! I have a few comments about it.

On 2022-09-05, Alexander Kanavin <alex.kanavin@gmail.com> wrote:
> This is the last (I believe) piece of the puzzle in setting up builds from nothing
> without having to write custom scripts or use external tools.

People can already setup the build-env without writing custom scripts or
using external tools. AFAICT, instead of users doing:

$ TEMPLATECONF=/some/template/dir . /path/to/oe-init-build-env /my/build/dir

you want them to do:

$ /path/to/oe-setup-build -c /some/template/dir -b /my/build/dir

As a yocto user, I am fine with how things have been. But I understand
that for new users, settings env-vars and sourcing files is unusual
(using the sdk relies on nearly the same procedure).

So if your motivation is to change from setting TEMPLATECONF and
sourcing oe-init-build-env to using an intuitive tool, then that should
be clearly stated in the commit message. It is not correct to say that
it cannot be setup without this tool because we've been doing it for
many years now. :-)

> After layers have been fetched and placed into their respective locations, one would
> surely want to proceed to the actual build, and here's how:
>
> 1. Without arguments, the tool simply walks the ../.. of its location (which is the parent dir
> of poky/oe-core), and prints what templates has found. If the following is not enough information,
> adding '-v' will also print conf-notes.txt for each of the templates:

For me this is not an intuitive interface. Below is a list of changes
that I would suggest:

1. The tool should be called "oe-setup-build-env". This matches the
source file "oe-init-build-env" and makes it clear that only a build
environment is setup and nothing will be "built".

2. The "-c" argument is required (also in your code), so not specifying
it should be an error. Upon printing the error message, the tool could
provide the help. Something like:

$ oe-setup-build-env
error: no template path specified with `-c'

usage: oe-setup-build-env -c template_path [-h] [--topdir TOPDIR] [-v] [-b build_path] [--no-shell]

A script that discovers available build configuration templates and sets up a build environment based on one of them

optional arguments:
  -h, --help        show this help message and exit
  --topdir TOPDIR   Where to look for available build configuration templates (default is ../..).
  -v                Print a description for each available build configuration template.
  -c template_path  Use build configuration template in template_path to set up a build (run this script without arguments or with -v to see what is available)
  -b build_path     Set up a build in build_path (run this script without arguments or with -v to see where it would be by default)
  --no-shell        Create a build but do not start a shell session with it.

(Or maybe template_path could be a positional argument instead of
specified with -c? Not sure.)

3. In the help output I think it is important to always talk about
build environments instead of builds. For example:

    Use build configuration template in template_path to set up a build environment

    Set up a build environment in build_path

    Create a build environment but do not start a shell session within it

4. Listing available templates is a nice feature, but this alternate
mode of operation should have its own argument. Something like

  -l                List available build configuration templates.

5. Your comments hint that this tool might be a second step for users of
the new "oe-setup-layers" tool. That tool uses a configuration file that
has an explicit list of layers that are used. But this tool recursively
searches for templates in _any_ layer under topdir. If this tool is
indeed meant as a second step to "oe-setup-layers" then perhaps it
should also support using the configuration file so that it knows which
layers it is allowed to list (or maybe even use).

  --jsondata        File containing the layer data in json format

With the json data available, the tool could also report if the layers
are dirty or are using a different commit, before setting up the build
environment.

John Ogness