Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

-p doesn't run a pristine build #28876

Closed
vandita5 opened this issue Oct 2, 2020 · 9 comments · Fixed by #28981
Closed

-p doesn't run a pristine build #28876

vandita5 opened this issue Oct 2, 2020 · 9 comments · Fixed by #28981
Assignees
Labels
area: West West utility bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug

Comments

@vandita5
Copy link

vandita5 commented Oct 2, 2020

Describe the bug
A clear and concise description of what the bug is.
What have you tried to diagnose or workaround this issue?
This has happened to me in different scenarios but I didn't document them before. In this case I checked out a new version of zephyr and ran west update. I then ran the build command with -p and it kept failing as it couldn't find ZEPHYR_BASE. I tried to follow instructions from getting started about running the shell script to set environment variables and set them manually too but still got the same error. I then deleted the build folder and tried building and it worked.
Command that I was running west build -p -b nucleo_f429zi samples\basic\blinky

To Reproduce
Steps to reproduce the behavior:

  1. west build -p -b nucleo_f429zi samples\basic\blinky (works fine)
  2. cd zephyrproject/zephyr
  3. git checkout zephyr-v2.3.0
  4. west update
  5. west build -p -b nucleo_f429zi samples\basic\blinky (gives error)
  6. delete build folder
  7. west build -p -b nucleo_f429zi samples\basic\blinky (no error)

Expected behavior
A clear and concise description of what you expected to happen.
I expected -p to create a pristine build and I didn't expect to have to delete build folder manually.

Impact
What impact does this issue have on your progress (e.g., annoyance, showstopper)
Annoyance

Logs and console output
If applicable, add console logs or other types of debug information
e.g Wireshark capture or Logic analyzer capture (upload in zip archive).
copy-and-paste text and put a code fence (```) before and after, to help
explain the issue. (if unable to obtain text log, add a screenshot)

Environment (please complete the following information):

  • OS: (e.g. Linux, MacOS, Windows) Windows
  • Toolchain (e.g Zephyr SDK, ...) zephyr samples with west setup.
  • Commit SHA or Version used - 2.3.0

Additional context
Add any other context about the problem here.

@vandita5 vandita5 added the bug The issue is a bug, or the PR is fixing a bug label Oct 2, 2020
@vandita5
Copy link
Author

vandita5 commented Oct 2, 2020

@mbolivar-nordic Created an issue as per our conversation on slack.

@mbolivar-nordic mbolivar-nordic self-assigned this Oct 3, 2020
@mbolivar-nordic mbolivar-nordic added area: West West utility priority: medium Medium impact/importance bug labels Oct 3, 2020
@mbolivar-nordic
Copy link
Contributor

Thanks! I will look into it.

@vandita5
Copy link
Author

vandita5 commented Oct 5, 2020

while trying to run build for a new app in the same folder, got this error. the -p auto should have cleaned up the previous build by itself, right?
image

@mbolivar-nordic
Copy link
Contributor

Hi @vandita5, and thanks again for the detailed report. I tried to reproduce this on Windows 10 but I can't. I get no error in your step 5. When doing a verbose build, I get:

> west -v build -p -b nucleo_f429zi samples\basic\blinky
ZEPHYR_BASE=C:\Users\Marti\zp\zephyr (origin: configfile)
-- west build: making build dir C:\Users\Marti\zp\zephyr\build pristine
cmake version 3.14.1 is OK; minimum version is 3.13.1
Running CMake: 'C:\Program Files\CMake\bin\cmake.EXE' -P C:/Users/Marti/zp/zephyr/cmake/pristine.cmake

Can you please help me understand what's going on on your computer by running this exact command in step 5:

> west -vvv build -p -b nucleo_f429zi samples\basic\blinky

Notice how there are three v's: -vvv, NOT -v, in the command I'd like you to run.

If you can copy/paste the output (screenshot if you must, but copy paste would be really preferred) here, I will try to figure out what is different on our computers.

@mbolivar-nordic mbolivar-nordic added the Waiting for response Waiting for author's response label Oct 5, 2020
@vandita5
Copy link
Author

vandita5 commented Oct 5, 2020

@mbolivar-nordic I tried doing this now but sadly couldn't reproduce it either. It is a bit finicky for me. I have to delete the build folder quite a few times when trying something new. like today I was trying to build for a custom board and saw this issue. I don't have a reproducer sadly but I will try running with -vvv when I encounter this problem next.

@vandita5
Copy link
Author

vandita5 commented Oct 5, 2020

I had a similar issue though it might not be the same. Today when I was trying to add a custom board, one error that I am able to reproduce was that when I gave the wrong BOARD_ROOT, changing it to the correct one and then running west build again always resulted in a permissions error. but running the build command one more time resolves or also resolved by deleting build folder.
steps:

  1. west build -p -b palmetto_core -s ..\firmwarezephyr\apps\thruput_characterization\ -- -DBOARD_ROOT="../firmwarezephyr/"
  2. west -vvv build -p -b palmetto_core -s ..\firmwarezephyr\apps\thruput_characterization\ -- -DBOARD_ROOT="C:/Users/vanditasharma/Documents/code/firmwarezephyr/" (permissions error)
  3. west -vvv build -p -b palmetto_core -s ..\firmwarezephyr\apps\thruput_characterization\ -- -DBOARD_ROOT="C:/Users/vanditasharma/Documents/code/firmwarezephyr/" (no error)
(base) PS C:\Users\vanditasharma\Documents\code\zephyrproject> west -vvv build -p -b palmetto_core -s ..\firmwarezephyr\apps\thruput_characterization\ -- -DBOARD_ROOT="C:/Users/vanditasharma/Documents/code/firmwarezephyr/"
args namespace: Namespace(command='build', help=None, verbose=3, zephyr_base=None)
ZEPHYR_BASE=C:\Users\vanditasharma\Documents\code\zephyrproject\zephyr\ (origin: env)
args: Namespace(board='palmetto_core', build_dir=None, build_opt=[], cmake=False, cmake_only=False, command='build', dry_run=False, force=False, help=None, pristine='always', source_dir='..\\firmwarezephyr\\apps\\thruput_characterization\\', target=None, verbose=3, zephyr_base=None) remainder: ['--', '-DBOARD_ROOT=C:/Users/vanditasharma/Documents/code/firmwarezephyr/']
source_dir: ..\firmwarezephyr\apps\thruput_characterization\ cmake_opts: ['-DBOARD_ROOT=C:/Users/vanditasharma/Documents/code/firmwarezephyr/']
setting up build directory
setting up source directory
config dir-fmt: build
build is NOT a valid zephyr build directory
build dir: build
pristine: always auto_pristine: False
C:\Users\vanditasharma\Documents\code\zephyrproject\build is NOT a valid zephyr build directory
setting up source directory
sanity checking the build
C:\Users\vanditasharma\Documents\code\firmwarezephyr\apps\thruput_characterization is NOT a valid zephyr build directory
-- west build: generating a build system
cmake version 3.16.2 is OK; minimum version is 3.13.1
Running CMake: 'C:\Program Files\CMake\bin\cmake.EXE' '-BC:\Users\vanditasharma\Documents\code\zephyrproject\build' '-SC:\Users\vanditasharma\Documents\code\firmwarezephyr\apps\thruput_characterization' -GNinja -DBOARD=palmetto_core -DBOARD_ROOT=C:/Users/vanditasharma/Documents/code/firmwarezephyr/ -DBOARD_FLASH_RUNNER=jlink
-- Application: C:/Users/vanditasharma/Documents/code/firmwarezephyr/apps/thruput_characterization
-- Zephyr version: 2.3.0 (C:/Users/vanditasharma/Documents/code/zephyrproject/zephyr)
-- Board: palmetto_core
-- Found west: C:/ProgramData/Miniconda3/Scripts/west.exe (found suitable version "0.7.2", minimum required is "0.7.1")
-- Found dtc: C:/ProgramData/chocolatey/bin/dtc.exe (found suitable version "1.4.7", minimum required is "1.4.6")
-- Found toolchain: gnuarmemb (C:/gnu_arm_embedded)
CMake Error at C:/Users/vanditasharma/Documents/code/zephyrproject/zephyr/cmake/compiler/gcc/generic.cmake:24 (message):
  Executing the below command failed.  Are permissions set correctly?

  'C:/Program Files (x86)/Microsoft Visual
  Studio/2019/Professional/VC/Tools/MSVC/14.24.28314/bin/Hostx64/x64/cl.exe
  --version'

Call Stack (most recent call first):
  C:/Users/vanditasharma/Documents/code/zephyrproject/zephyr/cmake/generic_toolchain.cmake:70 (include)
  C:/Users/vanditasharma/Documents/code/zephyrproject/zephyr/cmake/app/boilerplate.cmake:508 (include)
  CMakeLists.txt:5 (include)


-- Configuring incomplete, errors occurred!
See also "C:/Users/vanditasharma/Documents/code/zephyrproject/build/CMakeFiles/CMakeOutput.log".
FATAL ERROR: command exited with status 1: 'C:\Program Files\CMake\bin\cmake.EXE' '-BC:\Users\vanditasharma\Documents\code\zephyrproject\build' '-SC:\Users\vanditasharma\Documents\code\firmwarezephyr\apps\thruput_characterization' -GNinja -DBOARD=palmetto_core -DBOARD_ROOT=C:/Users/vanditasharma/Documents/code/firmwarezephyr/ -DBOARD_FLASH_RUNNER=jlink
=== Traceback (enabled by -vvv):
Traceback (most recent call last):
  File "c:\programdata\miniconda3\lib\site-packages\west\app\main.py", line 334, in run_command
    self.run_extension(args.command, argv)
  File "c:\programdata\miniconda3\lib\site-packages\west\app\main.py", line 397, in run_extension
    command.run(args, unknown, self.topdir, manifest=self.manifest)
  File "c:\programdata\miniconda3\lib\site-packages\west\commands.py", line 116, in run
    self.do_run(args, unknown)
  File "c:\users\vanditasharma\documents\code\zephyrproject\zephyr\scripts\west_commands\build.py", line 170, in do_run
    self._run_cmake(board, origin, self.args.cmake_opts)
  File "c:\users\vanditasharma\documents\code\zephyrproject\zephyr\scripts\west_commands\build.py", line 405, in _run_cmake
    run_cmake(final_cmake_args, dry_run=self.args.dry_run)
  File "C:\Users\vanditasharma\Documents\code\zephyrproject\zephyr\scripts/west_commands\zcmake.py", line 71, in run_cmake
    raise subprocess.CalledProcessError(p.returncode, p.args)
subprocess.CalledProcessError: Command '['C:\\Program Files\\CMake\\bin\\cmake.EXE', '-BC:\\Users\\vanditasharma\\Documents\\code\\zephyrproject\\build', '-SC:\\Users\\vanditasharma\\Documents\\code\\firmwarezephyr\\apps\\thruput_characterization', '-GNinja', '-DBOARD=palmetto_core', '-DBOARD_ROOT=C:/Users/vanditasharma/Documents/code/firmwarezephyr/', '-DBOARD_FLASH_RUNNER=jlink']' returned non-zero exit status 1.

@vandita5
Copy link
Author

vandita5 commented Oct 5, 2020

I'm not able to reproduce any of the other times that I had to delete build folder.

@mbolivar-nordic mbolivar-nordic removed the Waiting for response Waiting for author's response label Oct 5, 2020
@mbolivar-nordic
Copy link
Contributor

I see what's going on. I'll send a patch tomorrow after I've done some more testing. Thanks again.

@mbolivar-nordic
Copy link
Contributor

@vandita5 PR posted: #28981

mbolivar-nordic added a commit to mbolivar-nordic/zephyr that referenced this issue Oct 7, 2020
The west build command has historically tried not to rm -rf
directories that don't look like zephyr build directories. The way it
does this is by checking for the presence of a CMake cache
with a Zephyr-specific variable (ZEPHYR_TOOLCHAIN_VARIANT) in it.

The problem with this approach is that if the build system fails
before this cache variable is set, the directory doesn't look like a
zephyr build directory, and therefore west build won't make it
pristine even with --pristine=always, even though build directories
resulting from failed runs like that are almost certainly
irrecoverably broken and need to be made pristine before anything will
work.

This leads to users having to rm -rf their directories manually, which
is not so nice.

To avoid this from happening, just check for ZEPHYR_BASE, which is
set early on in ZephyrConfig.cmake in 'modern' zephyr build systems.
Keep the ZEPHYR_TOOLCHAIN_VARIANT check in place for compatibility.

We could consider being less selective and just using shutil.rmtree()
whenever we have --pristine=always, but that would be a bigger
behavioral change than I'm comfortable doing without a good reason.

Fixes: zephyrproject-rtos#28876
Signed-off-by: Martí Bolívar <[email protected]>
@ioannisg ioannisg added priority: low Low impact/importance bug and removed priority: medium Medium impact/importance bug labels Oct 13, 2020
galak pushed a commit that referenced this issue Oct 14, 2020
The west build command has historically tried not to rm -rf
directories that don't look like zephyr build directories. The way it
does this is by checking for the presence of a CMake cache
with a Zephyr-specific variable (ZEPHYR_TOOLCHAIN_VARIANT) in it.

The problem with this approach is that if the build system fails
before this cache variable is set, the directory doesn't look like a
zephyr build directory, and therefore west build won't make it
pristine even with --pristine=always, even though build directories
resulting from failed runs like that are almost certainly
irrecoverably broken and need to be made pristine before anything will
work.

This leads to users having to rm -rf their directories manually, which
is not so nice.

To avoid this from happening, just check for ZEPHYR_BASE, which is
set early on in ZephyrConfig.cmake in 'modern' zephyr build systems.
Keep the ZEPHYR_TOOLCHAIN_VARIANT check in place for compatibility.

We could consider being less selective and just using shutil.rmtree()
whenever we have --pristine=always, but that would be a bigger
behavioral change than I'm comfortable doing without a good reason.

Fixes: #28876
Signed-off-by: Martí Bolívar <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: West West utility bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants