Closed julianoes closed 5 years ago
Weird, I'll take a look. I suppose we should get a couple builds on Jenkins that don't use Ninja.
That would make sense. (Ceterum censeo ninja shouldn't be used.)
This is another warning/error that I get sometimes:
[ 4%] Copying NuttX config nsh and configuring
[ 4%] Generating nuttx/include/nuttx/version.h, nuttx/include/nuttx/config.h
make[5]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule.
/bin/sh: tools/mkversion: Permission denied
I'm not sure if it's related.
git bisect
points somewhere to the board organization:
There are only 'skip'ped commits left to test.
The first bad commit could be any of:
abb3817d3121b89e35b6774a4306c86a4616e5cf
cadda8c2630d12fb44cfdc567b68ad251b4f4435
f692ad04d0ea22b8874926e9dc0cac23263bbeae
2d052c02fae3c581a5947f01ace894c54dc1ffbb
We cannot bisect more!
This seems like a race condition in the nuttx part of the build. Almost like it's taking multiple dependency paths to the nuttx setup, but not recognizing that step as a single node and executing it twice.
Has it always be the case that the Makefile build is different from the ninja build?
$ ls -l | grep bin
-rwxr-xr-x 1 julianoes julianoes 1021685 Dec 19 09:43 px4_fmu-v2.bin.make
-rwxr-xr-x 1 julianoes julianoes 1021613 Dec 19 09:45 px4_fmu-v2.bin.ninja
$ xxd px4_fmu-v2.bin.make > px4_fmu-v2.bin.make.hex
$ xxd px4_fmu-v2.bin.ninja > px4_fmu-v2.bin.ninja.hex
$ diff px4_fmu-v2.bin.make.hex px4_fmu-v2.bin.ninja.hex | wc -l
40323
Is this still relevant?
Yes, the Makefile build is broken as far as I know, unless it has been fixed.
I found that the build works with -j1
.
@dagar I'm currently looking at:
/home/julianoes/src/Firmware/build/px4_fmu-v4_default/NuttX/nuttx/Make.defs:36: /home/julianoes/src/Firmware/build/px4_fmu-v4_default/NuttX/nuttx/.config: No such file or directory
and I don't understand why we copy the defconfig file twice:
@julianoes the defconfig now only contains non-default values and needs to be reconstituted at cmake configure time (cmake uses the variables).
I also found this:
Deleting primary custom command output "/home/julianoes/src/Firmware/build/px4_fmu-v4_default/NuttX/nuttx/.config" because another output "/home/julianoes/src/Firmware/build/px4_fmu-v4_default/NuttX/nuttx_config.stamp" does not exist.
Dependee "/home/julianoes/src/Firmware/build/px4_fmu-v4_default/NuttX/CMakeFiles/nuttx_apps_build.dir/DependInfo.cmake" is newer than depender "/home/julianoes/src/Firmware/build/px4_fmu-v4_default/NuttX/CMakeFiles/nuttx_apps_build.dir/depend.internal".
Dependee "/home/julianoes/src/Firmware/build/px4_fmu-v4_default/NuttX/CMakeFiles/CMakeDirectoryInformation.cmake" is newer than depender "/home/julianoes/src/Firmware/build/px4_fmu-v4_default/NuttX/CMakeFiles/nuttx_apps_build.dir/depend.internal".
And this:
Deleting primary custom command output "/home/julianoes/src/Firmware/build/px4_fmu-v4_default/NuttX/nuttx/.config" because another output "/home/julianoes/src/Firmware/build/px4_fmu-v4_default/NuttX/nuttx_config.stamp" does not exist.
Alright, I think this first deletion happens presumably because the file exists from the configure step. It only happens once and at the beginning so I don't think we have to worry about it.
Now, what I found is that the config copy steps are done multiple times if we have -j4
and not -j1
, so as you @dagar wrote above there are multiple dependency paths.
I have a really hard to time to understand all the dependencies in this file: https://github.com/PX4/Firmware/blob/d9f8e37288d8e34baac79b32d71862045946534b/platforms/nuttx/NuttX/CMakeLists.txt
Is there any way we could improve it and make it easier to understand as well as prevent make or cmake from getting confused?
I believe we're running into this: https://gitlab.kitware.com/cmake/cmake/issues/17585
I have it compiling again, I'll make a pull request soon.
I'm sometimes getting a build error when doing a clean build. I started looking into it but it's not obvious to me what happens. I've been able to reproduce it on Ubuntu 16.04 and Fedora 28 both times without ninja-build.
FYI: @bkueng @dagar