[Buildroot] [PATCH 7/8] core/show-info: report the ordered list of build steps

Philippe Proulx eeppeliteloop at gmail.com
Sat Apr 11 13:41:47 UTC 2020


On Sat, Apr 11, 2020 at 4:39 AM Thomas Petazzoni
<thomas.petazzoni at bootlin.com> wrote:
>
> On Sat, 11 Apr 2020 10:12:32 +0200
> "Yann E. MORIN" <yann.morin.1998 at free.fr> wrote:
>
> > People (and scritps) who want to report on the build progress, now know
> > where and what to look for (build directory and stampfiles), but they
> > also need to know the ordering of those stampfiles.
> >
> > The stampfiles item is a dictionary; dictionaries are guaranteed to not
> > be ordered, so even if we output the stampfiles in order, we can expect
> > users of that dictionary to get them back in order.
> >
> > Expose the build steps in a list, which is guaranteed to be ordered.
> >
> > Signed-off-by: Yann E. MORIN <yann.morin.1998 at free.fr>
> > Cc: Vadim Kochan <vadim4j at gmail.com>
> > Cc: Thomas Petazzoni <thomas.petazzoni at bootlin.com>
> > Cc: Arnout Vandecappelle <arnout at mind.be>
> > Cc: eeppeliteloop at gmail.com
> > ---
> >  package/pkg-utils.mk | 15 +++++++++++++++
> >  1 file changed, 15 insertions(+)
>
> Meh, just like PATCH 6/8, I'm not sure. This is going to be a lot of
> additional information in the JSON, almost duplicated for every
> package, and there is really nothing bad in the "progress showing" tool
> to have knowledge about these steps. It's not like they are changing
> all the time.

Replying for patch 6/8 and this one.

Is the `show-info` target considered a public API? If so, without a
version, it means it can never break. So let me suggest another layout
which breaks `show-info` (name it `show-info-2` if you will).

Output example (using YAML only for clarity here):

    version: 2
    build_steps:
      target:
        - name: download
          stamp_file: .stamp_downloaded
        - name: extract
          stamp_file: .stamp_extracted
        - name: patch
          stamp_file: .stamp_patched
        - name: build
          stamp_file: .stamp_configured
        - name: configure
          stamp_file: .stamp_built
        - name: install_staging
          stamp_file: .stamp_staging_installed
        - name: install_target
          stamp_file: .stamp_target_installed
        - name: install_image
          stamp_file: .stamp_image_installed
        ...
      host:
        - ...
      rootfs:
        - ...
    packages:
      target:
        libglib2:
          virtual: false
          version: 2.64.1
          licenses: LGPL-2.1+
          dl_dir: libglib2
          downloads:
            - source: glib-2.64.1.tar.xz
              uris:
                - http+http://ftp.gnome.org/pub/gnome/sources/glib/2.64
                - http|urlencode+http://sources.buildroot.net/libglib2
                - http|urlencode+http://sources.buildroot.net
          overriden: false
          build_dir: build/libglib2-2.64.1/
          build_steps:
            - download
            - extract
            - patch
            - build
            - configure
            - install_staging
            - install_target
          dependencies:
            - host-libglib2
            - host-meson
            - host-pkgconf
            - host-skeleton
            - host-tar
            - libffi
            - pcre
            - skeleton
            - toolchain
            - zlib
          reverse_dependencies:
            - cairo
        ...
      host:
        ...
      rootfs:
        ...

So, changes:

* A root `version` entry indicates the API version.

* The root `build_steps` object indicates all the _possible_ (sorted)
  build steps for each package type.

  Each build step in the array has its name and its corresponding
  stamp file to indicate when it's completed.

  As Yann wrote:

  > However, the names of those stamp files are purely an implementation
  > detail (even if they are very unlikely to ever change).

* The root `packages` object contains the package information for each
  package type.

  Not strictly related to this patch or the previous one, but instead
  of repeating the type in each object, you can just group packages
  by type.

* For each package object, the `build_steps` array indicate what are the
  build steps for this package.

  Each item is the name of a build step in the corresponding root
  `build_steps` object's array.

* For a target package, the `install_staging`, `install_target`, and
  `install_images` entries are removed.

  They are not needed anymore because `build_steps` offers the same
  information.

  I understand some build steps could be implicit and not listed here,
  but with my suggestion, you already have what's needed for any build
  monitoring tool to watch a specific package build process if:

  * Some of the implicit build steps become optional in the future for
    any reason that you don't know now.

  * You add new types of build steps: simply describe them in the
    `build_steps` root arrays.

  Both scenarios won't require an API version bump.

If you're not willing to break `show-info` and don't want `show-info-2`,
then you can:

* Keep `show-info` as is:

  * Augment a package information with `build_steps` (like above).

  * Keep the `install_*` entries which become redundant.

* Have another make target, say `show-build-steps`, which only prints
  the root `build_steps` object above.

What do you think?

Phil

>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com



More information about the buildroot mailing list