Ability to run without setting ZEPHYR_BASE

[koffes]

Looking at the doc: https://docs.zephyrproject.org/latest/boards/native/nrf_bsim/doc/nrf52_bsim.html
some variables such as:

export BSIM_OUT_PATH=${ZEPHYR_BASE}/../tools/bsim
export BSIM_COMPONENTS_PATH=${BSIM_OUT_PATH}/components/

are dependent on ZEPHYR_BASE.
We have seen issues where users have multiple Zephyr folders, and the ZEPHYR_BASE points to the wrong one. This is indeed a user fault, but a very simple trap to fall into.
If there is some way to dynamically find this path/ omit the need for these env. vars. that would simplify usage and remove a pitfall.

This may be related to zephyrproject-rtos/zephyr#82058

[aescolar]

@koffes
( Note this is a Zephyr documentation issue more than babblesim :) )
The description in that page is just how to setup a "quick default" for Zephyr development.
If you have several Zephyr workspaces, things will work if you also have the babblesim group enabled in each (as you will refer to the bsim installation in that Zephyr workspace)
If you have only 1 babblesim installation that you want to reuse between Zephyr workspaces ¹ you should set BSIM_OUT_PATH to point to the absolute folder of that singular bsim installation.

Footnotes

1. which you can do as babblesim is backwards compatible, you just need to keep it updated to the latest. ↩

[alwa-nordic]

It's possible to grab it dynamically like this:

(unset ZEPHYR_BASE; t="$(west topdir)" && echo "$t/$(west config zephyr.base)")

Though we should probably not unset ZEPHYR_BASE, so it is respected when set and only dynamic when not set.

[aescolar]

It's possible to grab it dynamically like this:

I'm not sure I follow. Environment variables are fixed when you set them.
In any case, ZEPHYR_BASE is normally set in the shell by zephyr-env.sh, which you'd call when switching from one zephyr workspace to another.
If you set the BSIM_* env vairables in ~/.zephyrrc' they will be set also when calling zephyr-env.sh`.

[alwa-nordic]

It's possible to grab it dynamically like this:

I'm not sure I follow.

I just mean it as a way to compute a fallback for ZEPHYR_BASE based on output from west. Alternatively, we could automatically source zephyr-env.sh?

[alwa-nordic]

west says the following about default ZEPHYR_BASE:

$ west --help
usage: west [-h] [-z ZEPHYR_BASE] [-v] [-V] <command> ...

The Zephyr RTOS meta-tool.

optional arguments:
  -z ZEPHYR_BASE, --zephyr-base ZEPHYR_BASE
                        Override the Zephyr base directory. The default is
                        the manifest project with path "zephyr".

[aescolar]

I think we are mixing things a bit here.
@koffes seemed to be asking about how is BSIM_OUT_PATH set, for the the scripts that run the tests.
This is just used to know where to find the simulator and the executables that were just build (which is in ${BSIM_OUT_PATH}/bin/)
Now, a user can have the simulator whereever they please. That's why they can set those variables. Different users will have different setups. And if we are talking about users having more than one zephyr workspace and maybe sharing or not the bsim installation between them, there is no right answer to "where is the simulator".
We could start adding boilerplate in every script to try to guess things if nothing is set, but I doubt it will be worthwhile.

But maybe, @koffes, can you elaborate on what is the problem? (and maybe tell if this problem is really worth while, or are we knee-jerk to a minor annoyance?)

[koffes]

I'd argue this is more than a minor annoyance, but also not critical.
The root cause is that ZEPHYR_BASE IMO is a pain in the neck when working with multiple zephyr trees, and I believe it should not be used at all.

The issue arises when having code of version A in <zephyr_folder_A>/../tools/bsim and then starting working on something else in <zephyr_folder_B>/.... One then wrongly assumes that <zephyr_folder_B>/../tools/bsim code is being executed, but this is not the case.

A solution would be to either dynamically deduct the current Zephyr root, and/or print a warning if you are running tests in tree B whilst BSIM_COMPONENTS_PATH points to tree A.

[koffes]

Ref. our discussion today @aescolar :)