Should write to auto.conf not local.conf?

[rossburton]

Strictly speaking, auto.conf is where automatically written configuration should go, not local.conf.

I was only thinking about this because of the possibility of using kas as a starting point for builds. If it wrote to auto.conf then re-running kas could just rewrite the managed configuration, leaving local.conf for the user to further alter.

[jan-kiszka]

Thanks for pointing this out. However, I think that auto.conf is an OE-only concept. I do not find this pattern in generic bitbake. But we could discuss this further via the list, whether and how to add this variant.

[NGenetzky]

@rossburton , I would say that I have thought the same thing. So I'm glad you asked it.

@jan-kiszka , Being someone who also uses Bitbake without OE I appreciate your efforts to focus on Bitbake centric functionality. To play devil's advocate I would note that the MACHINE and DISTRO (and one other) key are OE specific. On top of that, these keys are included in local.conf by default.

[vivien]

Here's a new syntax I would like to suggest, keeping kas environment-agnostic, flexible and retro-compatible with the older syntax.

Any entry under a top-level conf key corresponds to a configuration file to be created under ${TOPDIR}/conf with the provided content, like conf/local.conf or conf/multiconfig/product1.conf in the example below.

header:
  version: 11

conf:
  auto: |
    BB_DISKMON_DIRS = "\
        STOPTASKS,${TMPDIR},1G,100K \
        STOPTASKS,${DL_DIR},1G,100K \
        STOPTASKS,${SSTATE_DIR},1G,100K \
        STOPTASKS,/tmp,100M,100K \
        ABORT,${TMPDIR},100M,1K \
        ABORT,${DL_DIR},100M,1K \
        ABORT,${SSTATE_DIR},100M,1K \
        ABORT,/tmp,10M,1K \
        "

  site: |
    BB_GENERATE_MIRROR_TARBALLS = "1"
    DL_DIR = "${TOPDIR}/../downloads"
    SSTATE_DIR = "${TOPDIR}/../sstate-cache"

  local: |
    MACHINE ??= "qemux86"
    DISTRO ??= "poky"
    BBMULTICONFIG ?= "product1 product2"
    IMAGE_FEATURES:append = " debug-tweaks"

  multiconfig:
    product1: |
      MACHINE = "mach1"
      TMPDIR = "${TOPDIR}/tmp/product1"

    product2: |
      MACHINE = "mach2"
      TMPDIR = "${TOPDIR}/tmp/product2"

The rational behind this is that IMO kas should be flexible enough to eventually create the configuration for you, or use the one you provide, without enforcing anything. Also, we see some CI/CD using either auto.conf or site.conf to override settings, so it must be up to the user in the end to define their build system policy.

Pushing further, one may provide conf: bblayers: directly if kas is only used to factorize the build configuration but not fetching layers, or the opposite, using kas only as an alternative to git submodules and place their own conf directory under version control without kas altering them.

To summarize, the new syntax must ensure to ease the following OPTIONAL steps:

• fetch/patch layers
• generate the configuration under ${TOPDIR}/conf
• invoke bitbake

(This comment focuses on the second step, the config generation.)

[jan-kiszka]

Thanks for such a concrete proposal. Please start a discussion on this on the mailing list, also because this goes way beyond the original topic.

[jan-kiszka]

There hasn't been a follow-up on this on the list, has there?