So, I ran “sudo make clean” in the source directory because in the past that’s been necessary to get changes to airframe config files to take effect. However today when I ran “sudo make px4fmu-v3_default” right after that, it told me there was no recipe for the target. I’m not very familiar with cmake, so… any idea what I did to deserve this? D:
Why are you using
sudo? Should not be necessary.
Anything that adds or removes files seems to want a sudo on my machine/profile…
Sounds like you have some permission issues with your directories. Is the
Firmware directory and all its subdirectories owned by you and not
root or anyone else? Don’t know if this is related to your original issue but it might indicate that you have some issues with your setup.
Hmm, looks like the Firmware directory is owned by me, but the build directories and makefiles are owned by root. How do I/should I change this?
They are probably owned by
root because of the
sudo make ... calls. You can either manually delete them with
sudo rm -rf build..., or with
sudo make clean. Then
make px4fmu-v3_default should not have any permission issues.
Ok, here’s the output for “make px4fmu-v3_default” following “sudo make clean”:
anna@compy:~/src/Firmware$ make px4fmu-v3_default -- CMAKE_MODULE_PATH: /home/anna/src/Firmware/cmake -- Nuttx build for px4fmu-v3 on m4 hardware, using nsh with ROMFS on px4fmu_common -- Build Type: RelWithDebInfo -- PX4 VERSION: v1.6.2-104-ge132605 -- CONFIG: nuttx-px4fmu-v3-default -- CMAKE_INSTALL_PREFIX: /usr -- C compiler: cc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 -- C++ compiler: c++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 -- Using C++03 -- Release build type: RelWithDebInfo -- Adding UAVCAN STM32 platform driver -- Adding ROMFS on px4fmu-v3 -- Nuttx build for px4fmu-v3 on m3 hardware, using nsh -- Configuring done CMake Error: Unable to open check cache file for write. /home/anna/src/Firmware/CMakeFiles/cmake.check_cache /bin/sh: 1: cd: can't cd to /home/anna/src/Firmware/build_px4fmu-v3_default Makefile:164: recipe for target 'px4fmu-v3_default' failed make: *** [px4fmu-v3_default] Error 2 anna@compy:~/src/Firmware$
Have you made any changes to the code? Have you tried cloning the firmware in a new directory and building? Can you post the output of
ls -al and
Yes, lots of changes… I re-cloned it in a new directory and the “no recipe” issue cleared up, but I still need sudo to build. Looks like I own everything but the build directory.
The reason you don’t own the build directory is because it is created by the
make command. If you run that with
sudo, i.e. as
root, that’s who will own it.
Right, but if I don’t run as root, the build just fails (that’s that output I pasted above)-- it says it can’t cd to the build directory. After this error occurs, the build directory won’t exist (even if I created one ahead of time, before running “make px4 etc”).
This same error occurs in the new Firmware clone? Did you clone PX4 master or your modified version? What system are you on and where are you cloning the Firmware into?
Yes, I wonder if there’s some wonky permissions thing going on with my computer (running Ubuntu 16.04). I cloned the PX4 master into a new folder in my home directory and the same thing happens.
Did you try other build targets?
Perhaps a problem with the way you installed the build toolchain? Did you follow the PX4 dev guide instructions? Did you perhaps install some python modules using sudo and now they aren’t usable for your user?
You’ve always had to use
That’s an interesting thought about the python modules, it’s very possible I installed using sudo. I followed the dev guide instructions for the toolchain install but that was months ago so I don’t remember if I deviated from anything it said. I’ve always had to use sudo, for any/all build targets. I guess if it gives me any more trouble I’ll redo the toolchain install, or try installing and building on another computer.
You could try setting up a
virtualenv and installing the required python modules (the ones you did not install with
apt) to see if that fixes it. That would be an easily undoable way to test it.
But I don’t know that this is the root of your “not recipe” problem anyway, doesn’t seem to be since re-cloning fixes that.
If you checkout master in your original Firmware directory do you still get the error or is it only with your changes? (also do a
make clean; make submodulesclean after checking out master)