Zephyr: Can we get rid of zephyr-env.sh?

[ulfalizer]

It feels pretty clunky to me whenever I have to run scripts or manually set environment variables to build a project. I wonder if we could give variables sensible defaults so that most users won't have to bother with them.

The sample CMakeLists.txt files do

include($ENV{ZEPHYR_BASE}/cmake/app/boilerplate.cmake NO_POLICY_SCOPE)

Maybe they could just use a relative path instead:

include(../../cmake/app/boilerplate.cmake NO_POLICY_SCOPE)

For ZEPHYR_SDK_INSTALL_DIR, maybe there could be a default install location, so that you'd only have to set it manually if you install the SDK somewhere else.

I guess zephyr-env.sh could still be kept around for backwards compatibility, if needed.

Any other stuff that would get tricky?

[ulfalizer]

CC @SebastianBoe

[zerotri]

Part of the benefit to having the zephyr-env.sh set ZEPHYR_BASE is that you can copy a sample project to just about anywhere on your system and cmake can find it to build your out of tree project.

You could always set these environment variables in your profile and then you'll never have to source the env file unless you move things.

[SebastianBoe]

Part of the benefit to having the zephyr-env.sh set ZEPHYR_BASE is that you can copy a sample project to just about anywhere on your system and cmake can find it to build your out of tree project.

You could always set these environment variables in your profile and then you'll never have to source the env file unless you move things.

+1

Additionally, zephyr-env.sh sources .zephyrrc, so we wouldn't be able to get rid of it without breaking compatibility. But it is, as @zerotri notes, optional to use (I don't use it personally).

There was an attempt at deprecating it by replacing it with a CMake-equivalent, but that was not received well. That PR has some additional discussion on zephyr-env.sh.

https://github.com/zephyrproject-rtos/zephyr/pull/9801

[ulfalizer]

Part of the benefit to having the zephyr-env.sh set ZEPHYR_BASE is that you can copy a sample project to just about anywhere on your system and cmake can find it to build your out of tree project.

Maybe we could explain that people need to include cmake/app/boilerplate.cmake from the Zephyr root:

Your application CMakeLists.txt file must include the
cmake/app/boilerplate.cmake file from the Zephyr root directory.

If you are building your application outside of the Zephyr source tree, we
recommend setting an environment variable called ZEPHYR_BASE to point to
the Zephyr root directory:

    export ZEPHYR_BASE=/path/to/zephyr
    *Some instructions on how to set it on Windows and make it persistent*

That way, your application's CMakeLists.txt can be written in a generic
style, which is good if multiple developers work on it:

    include($ENV{ZEPHYR_BASE}/cmake/app/boilerplate.cmake NO_POLICY_SCOPE)

Note: The name 'ZEPHYR_BASE' has no special significance, but is used elsewhere
in the Zephyr code, so we recommend it for consistency.

Here's the advantages I see with that:

1. Building the samples will work straight away. No need to run a magic script
   or change shell configuration files.

2. Simple to understand and less of a black box. I think the script is only
   documented as "set up your build environment" now.

3. Maybe at some point we could get rid of zephyr-env.sh and zephyr-env.cmd.

4. Linux devs won't be scared away by what looks like forcing people to set
   srctree or pass O= to Make every time. Even if we had a reason for it or
   our organization is a bit different, it might look bad coming from there.

[arjunak234]

It also makes the assumption that everyone uses bash as their shell.

[arjunak234]

Here's the advantages I see with that:

1. Building the samples will work straight away. No need to run a magic script
   or change shell configuration files.

2. Simple to understand and less of a black box. I think the script is only
   documented as "set up your build environment" now.

3. Maybe at some point we could get rid of `zephyr-env.sh` and `zephyr-env.cmd`.

4. Linux devs won't be scared away by what looks like forcing people to set
   `srctree` or pass `O=` to Make every time. Even if we had a reason for it or
   our organization is a bit different, it might look bad coming from there.

1. It makes it easier to import the project into IDEs that supports cmake projects (like qtcreator)

[d3zd3z]

I might also suggest the direnv utility, which allows a .envrc to be placed in various directories and the environment changes it makes will be backed out when the user cds to another directory.

[nashif]

I guess the answer is no, if there is a proposal for a better solution, this should come in as an RFC or a feature request.