New feature proposition

[Mateusz Koza]

Hi,

This is our project structure:
```
astra
├── build
├── meta-grinn-astra <-- our meta-layer with kas files
├── meta-browser
├── meta-clang
├── meta-deepx-m1
├── meta-lts-mixins
├── meta-openembedded
├── meta-qt5
├── meta-selinux
├── meta-swupdate
├── meta-synaptics
├── meta-virtualization
└── poky
```

Currently we execute kas-container the following way:
```
cd astra

kas-container build \
meta-grinn-genio/kas/default.yml:meta-grinn-genio/kas/nda.yml
```

We would like to execute kas-container with the following command:
```
cd astra

KAS_FILES_DIR=meta-grinn-genio/kas
kas-container build \
default.yml:nda.yml
```

We are aware the THE KAS_BUILD_DIR exists, we would just prefer to run
kas directly from the root of the project and not having to cd into the
kas files dir.

Is it something that would be accepted if we submit a patch for it? Or
is there any reason why it should not be implemented?

Best Regards,
Mateusz Koza

[Jan Kiszka]

On 08.04.26 13:54, Mateusz Koza wrote:
> Hi,
>
> This is our project structure:
> ```
> astra
> ├── build
> ├── meta-grinn-astra        <-- our meta-layer with kas files
> ├── meta-browser
> ├── meta-clang
> ├── meta-deepx-m1
> ├── meta-lts-mixins
> ├── meta-openembedded
> ├── meta-qt5
> ├── meta-selinux
> ├── meta-swupdate
> ├── meta-synaptics
> ├── meta-virtualization
> └── poky
> ```
>
> Currently we execute kas-container the following way:
> ```
> cd astra
>

Is astra itself already under version control?

> kas-container build \
> meta-grinn-genio/kas/default.yml:meta-grinn-genio/kas/nda.yml
> ```
>
> We would like to execute kas-container with the following command:
> ```
> cd astra
>
> KAS_FILES_DIR=meta-grinn-genio/kas
> kas-container build \
> default.yml:nda.yml
> ```
>
> We are aware the THE KAS_BUILD_DIR exists, we would just prefer to run
> kas directly from the root of the project and not having to cd into the
> kas files dir.
>
> Is it something that would be accepted if we submit a patch for it? Or
> is there any reason why it should not be implemented?
>

The original envision structure and workflow was

my-repo/
kas.yaml
meta-my-a
meta-my-b

git clone my-repo
cd my-repo
kas build kas.yaml

That would, by default, add more dirs to my-repo:

build
meta-external-a
meta-external-b
bitbake

etc.

To avoid those accumulations, KAS_WORK_DIR can be set to direct them
into a separate folder, even out-of-sight for my-repo.

Now the question is where you want or need to divert from the above, and
then we can think about how to embed that best into existing interfaces
and logic of kas.

Jan

--
Siemens AG, Foundational Technologies
Linux Expert Center

[Mateusz Koza]

Yes, meta-grinn-astra is already under version control. We decided to
manage everything under a single repository to keep things simpler for
us, even though it might not be the best practice. We keep multiple of
our meta-layers as well as kas configuration files in the same repo.
All the external dependencies are pulled in using kas. You can find
this repo at:

https://github.com/grinn-global/meta-grinn-astra

Our current workflow is as follows:

mkdir astra
cd astra
git clone https://github.com/grinn-global/meta-grinn-astra.git

KAS_MACHINE=grinn-astra-1680-evb \
kas-container build meta-grinn-astra/kas/default.yml

I hope this explains how we divert from the original structure.

[Jan Kiszka]

On 08.04.26 16:11, Mateusz Koza wrote:
> Yes, meta-grinn-astra is already under version control. We decided to
> manage everything under a single repository to keep things simpler for
> us, even though it might not be the best practice. We keep multiple of
> our meta-layers as well as kas configuration files in the same repo.
> All the external dependencies are pulled in using kas. You can find
> this repo at:
>
> https://github.com/grinn-global/meta-grinn-astra
>
> Our current workflow is as follows:
>
> mkdir astra
> cd astra
> git clone https://github.com/grinn-global/meta-grinn-astra.git
>
> KAS_MACHINE=grinn-astra-1680-evb \

Rather than using a variable, I would suggest having another kas file
that includes default.yml and sets the machine. Or using config
fragments also for machine selection.

> kas-container build meta-grinn-astra/kas/default.yml
>
> I hope this explains how we divert from the original structure.

So, you are building out-of-tree from kas perspective. What speaks
against building inside the checked-out repo? One cd less? But still one
env variable more.

I partially get your point that, when using config fragments
extensively, there is some repetition when specifying their paths. We
have this case in other projects as well, e.g.

kas.yaml:kas/board/qemu-amd64.yaml:kas/opt/xenomai-next.yaml:kas/opt/debug.yaml:kas/opt/linux-6.18-head.yaml:kas/opt/ci.yaml

But due to the folder structure we use, there is actually no common
path. We would have to put all files in the same folder to benefit from
a KAS_FILES_DIR prefix variable, mixing options with machines or other
fragment types.

What could be some common benefit would be some kind of
"KAS_FILES_PATH=kas/board:kas/opt" ie. a path list. OTOH, this will be
more complicated to implement, and it comes with the risk of making
things less readable or even causing name collisions/confusions. Hmm...

[Jan Kiszka]

BTW, such long configuration lines were one of reason to introduce the
kconfig menu. That is also what the users of this example are normally
operating with - unless they want to replicate the CI build I copied
from locally.

Jan

[Mateusz Koza]

On Wed, Apr 08, 2026 at 05:09:07PM +0200, Jan Kiszka wrote:
>> Rather than using a variable, I would suggest having another kas file
>> that includes default.yml and sets the machine. Or using config
>> fragments also for machine selection.

What is the benefit of adding another kas file here? For us it would
mean the command to be even longer.

>> So, you are building out-of-tree from kas perspective. What speaks
>> against building inside the checked-out repo? One cd less? But still one
>> env variable more.

The main reason is that we designed both of our meta-layers:
- https://github.com/grinn-global/meta-grinn-genio
- https://github.com/grinn-global/meta-grinn-astra
like meta-openembedded, that is a "meta" meta-layer that contains other
meta-layers inside. We provide System-On-Modules, hence we want our
users to use this meta-layer as a part of their own project. That being
said it seems kind of odd to have the build and work directory inside
the meta-layer itself, and this is the main reason why we are building
out-of-tree.

>> I partially get your point that, when using config fragments
>> extensively, there is some repetition when specifying their paths. We
>> have this case in other projects as well, e.g.
>>
>> kas.yaml:kas/board/qemu-amd64.yaml:kas/opt/xenomai-next.yaml:kas/opt/debug.yaml:kas/opt/linux-6.18-head.yaml:kas/opt/ci.yaml
>BTW, such long configuration lines were one of reason to introduce the
>kconfig menu. That is also what the users of this example are normally
>operating with - unless they want to replicate the CI build I copied
>from locally.

I haven't personally used the kconfig menu extensively, but given my
current understanding, it would probably make things a bit more
complicated for our users. We want the Quick Start Guide to be as simple
as possible and instructing the user to run the kas menu command and
then select the right options from the menu might be a bit too much for
them. For now it's just simple copy-paste kas build command with
everything already specified. You can see that in the Quick Start Guide:

https://wiki.grinn-global.com/products/genio/grinn-genio-700-sbc/build_the_image.html#build-the-nda-image

>> But due to the folder structure we use, there is actually no common
>> path. We would have to put all files in the same folder to benefit from
>> a KAS_FILES_DIR prefix variable, mixing options with machines or other
>> fragment types.

>> What could be some common benefit would be some kind of
>> "KAS_FILES_PATH=kas/board:kas/opt" ie. a path list. OTOH, this will be
>> more complicated to implement, and it comes with the risk of making
>> things less readable or even causing name collisions/confusions. Hmm...

I agree that doing it with a path list would be more complicated to even
read and understand. Although, given your example you could at least
strip off the "kas/", thanks to which your kas build command would look
like this:

kas.yaml:board/qemu-amd64.yaml:opt/xenomai-next.yaml:opt/debug.yaml:opt/linux-6.18-head.yaml:opt/ci.yaml

Best regards,
Mateusz