zephyrproject-rtos / west

West, Zephyr's meta-tool
https://docs.zephyrproject.org/latest/guides/west/index.html
Apache License 2.0
215 stars 117 forks source link

Introduce absolute path variant of zephyr.base #677

Closed mikaelj closed 10 months ago

mikaelj commented 11 months ago

Currently the path set in zephyr.base is relative. If one needs an absolute path, you must set it using the ZEPHYR_BASE variable.

I'd like a zephyr.base-absolute (or whatever you want to call it).

Also, updating the documentation would be helpful -- currently it is not stated, without looking at the west.py source code, that the variable points to a relative path.

https://github.com/zephyrproject-rtos/west/blob/92c18ac55acd631c11f9d4392556d3b7075a0bec/src/west/app/main.py#L694-L695C44

marc-hb commented 10 months ago

What specific problem(s) would this solve?

BTW ZEPHYR_BASE was a basically a design mistake:

west is mostly independent of Zephyr and should become totally independent.

marc-hb commented 10 months ago

What specific problem(s) would this solve?

Last call before closing?

mikaelj commented 10 months ago

@marc-hb to define a standard board for my build, I'd like a west config file. However, as soon as it's defined, zephyr is not found. So i'm forced to manually specify the default board to build for.

marc-hb commented 10 months ago

I still don't understand sorry. I ran west config --global build.board qemu_x86 and everything worked fine.

Please provide a specific sequence of commands that is causing an issue.

mikaelj commented 10 months ago

Okay, tried it with --local, which works. What I want is for the setting to be project local, i.e. stuff in my local directory, like a .west.config or whatever file.

I'm using the Nordic Connect Zephyr, so I'm guessing it's actually set semi-globally, i.e. for all projects using NCS Zephyr.

I suppose I'm just using West wrong, then...

marc-hb commented 10 months ago

Okay, tried it with --local, which works.

So is there any issue left?

What I want is for the setting to be project local, i.e. stuff in my local directory, like a .west.config or whatever file.

"local" directory is unfortunately vague, I guess you mean "in my workspace"? https://docs.zephyrproject.org/latest/develop/west/config.html

so I'm guessing it's actually set semi-globally, i.e. for all projects using NCS Zephyr.

No, west has no "semi-global" option and it cannot tell which workspace are NCS versus not.

I suppose I'm just using West wrong, then...

We cannot tell until you share a specific list of commands that reproduces the issue. A reproduction ideally without nrfConnect but much better with nrfConnect than no reproduction at all.

Without a reproduction, I also miss how this can be all related to an absolute zephyr.base

mikaelj commented 10 months ago

It's really quite simple. Here's what I want.

  1. download nRF Connect so I can use Zephyr on the nRF platform
  2. create a directory for my app, add a bunch of sources, start hacking
  3. set the default board for use by subsequent invocations of "west build"
  4. west build

I thought 3) would be solved by creating a .west/west.yml file in my project directory, with build.board set to something causes the issue to occur, for me, using the zephyr provided with nRF Connect.

I did this since I thought it would set default parameters for the west tool when running in this directory - so I could have per-project setting for which board to use. An app directory w/ source code that does not contain the entire 480M of Zephyr checked out. Since I have many apps on-going, that is a solution I very much not want.

But "project" in west != "an application using the zephyr toolkit", but instead something completely else which I'm yet to grasp.

So in summary, what I want to do is not possible.

The soluton I'll be using is a ./build.sh with "west build -p -b my_board".

Thanks for the effort and patience.

marc-hb commented 10 months ago

An app directory w/ source code that does not contain the entire 480M of Zephyr checked out. Since I have many apps on-going, that is a solution I very much not want.

OK, now I think I finally understand the problem. What I think you want is to share Zephyr code between multiple apps to save disk space, correct?

There are multiple ways to do this and some of them might even let you have separate west config build.board but they're all easier if you git checkout your applications inside a west workspace (whether the apps are listed in a west manifest or not). Despite this issue being filed about zephyr.base, I think you still haven't described the directory structure you'd like. Please provide a "picture" similar to one of these:

https://docs.zephyrproject.org/latest/develop/west/workspaces.html#topologies-supported

mikaelj commented 10 months ago

My directory structure is simply this.

~/code/goride/fw/zephyr-test:

./CMakeLists.txt ./LICENSE ./prj.conf ./README.md ./src ./src/main.c

That's the same way I write code for other frameworks, such as Flutter, where the framework/lib lives in a read-only directory somewhere on disk, and my code lives in my git repository. I don't have the Flutter framework checked out in my source code directory, nor in any directly ascending parent directories. Instead, it's in /opt/flutter. Which is akin to nRFConnect/Zephyr residing somewhere under /opt/nordic/....

Then I run some sort of build command. For Flutter, it's "flutter build". For Zephyr, I figured out it was "west build". I thought, from the documentation, that there was a way to set default parameters to west, for my specific project. Project, by my definition, is the source code I have written, for the resulting binary I am expecting to be produced by the build command.

Maybe I'm misunderstanding your question.

marc-hb commented 10 months ago

Maybe I'm misunderstanding your question.

I don't think that's the main problem. I think the main "communication issue" is you making a ton of assumptions that everyone uses Zephyr and west the same way as you (or... Flutter?!) do. The bad news is: no, a lot of people do NOT use west as you do. This should be pretty obvious after even a very quick look at https://docs.zephyrproject.org/latest/develop/west/workspaces.html#topologies-supported

So you when reporting a bug, you must describe in verbose detail your configuration. When reporting a bug about zephyr.base, you must especially describe your directory structure (which you finally did, thanks!)

Also, suggesting fixes is great but that does not make describing the issue optional https://en.wikipedia.org/wiki/XY_problem

marc-hb commented 10 months ago

to define a standard board for my build, I'd like a west config file.

Did you mean a west manifest (e.g. west.yml ) or west config commands?

However, as soon as it's defined,

How did you define what? Share specific commands, not just plain English.

zephyr is not found.

Copy/paste a specific error message.

So i'm forced to manually specify the default board to build for.

I think you later shared a command for that one, thanks.

Okay, tried it with --local, which works.

I think I guessed what you did but next time copy/paste the complete command AND the directory where you ran it.

So if you don't have time to spend understanding how west works, just stop there and everything OK? Or is there still some error message?

If you want to go further, read these two pages: https://docs.zephyrproject.org/latest/develop/west/basics.html https://docs.zephyrproject.org/latest/develop/west/config.html

I thought 3) would be solved by creating a .west/west.yml file in my project directory,

This is a manifest, it's not a "configuration file". It does nothing until you run west init, which you do NOT want to run again if you already have. It's unrelated to west config.

with build.board set to something causes the issue to occur,

How did you set build.board? It's unrelated to west.yml.

marc-hb commented 10 months ago

I haven't tried it myself but if you don't want to spend time understanding west I've heard good things about https://docs.platformio.org/en/latest/frameworks/zephyr.html

mikaelj commented 10 months ago

Let's just call it a day. Thanks for the alternative suggestion and links to the documentation.