search

PX4 / PX4-Autopilot

PX4 Autopilot Software
https://px4.io
BSD 3-Clause "New" or "Revised" License
8.22k stars 13.39k forks source link

Fork of the PX4 repository is not building #21644

Closed mandralis closed 11 months ago

mandralis commented 1 year ago

Hi everyone,

I have a simple problem. When i clone the px4 repository and run make px4_sitl gazebo-classic everything is working fine.

However, when I first fork the repository and then clone and run make px4_sitl gazebo-classic the codebase is no longer building.

The error I am getting is the following:

Error: /src/PX4-Autopilot-Fork/build/px4_sitl_default is not a directory

And in specific, the error begins with:

CMake Error at CMakeLists.txt:129 (list):
  list index: 1 out of range (-1, 0)

To reproduce this bug, you can build using the px4io/px4-dev-ros2-foxy:latest docker container.

Thanks in advance for the guidance on this issue.

dagar commented 1 year ago

I can try to reproduce tomorrow, but for now does make px4_sitl_default gazebo_iris work?

DaojiePENG commented 1 year ago

I also encontered this problem while make px4_sitl_default jmavsim also didn't work. Have solve this problem?

noahbliss commented 1 year ago

This is definitely a problem. It seems to arise from some sort of autoparsing of git tags in the CMakeLists.txt file. I guess when you fork, its internal logic breaks and ends up with fewer args than it expects or something like that.

noahbliss commented 1 year ago

Looks like this is present when the fork is of main (without any tags). I was able to get around it by going to my repo and running: git tag v1.14.0-dev From there, build went fine.

julianoes commented 11 months ago

Right, or you need to add upstream and fetch the tags, e.g.

git remote add upstream https://github.com/PX4/PX4-Autopilot.git
git fetch upstream
git fetch upstream --tags
hamishwillee commented 10 months ago

@julianoes @dagar I just got this error when installing to WSL2 Ubuntu 22.04.

It all works if you clone upstream - you can build main, or fetch a branch or whatever.

However if you want to contribute then you fork and setup following the git examples instructions. Those don't mention the need for tags from upstream.

Why should you need all upstream tags to build main or PX4 v1.14 from a synced repo? That seems ... weird. Is this just a case where we're never going to know so we should just update the instruction? I hate that - but better than everyone running into these problems.

noahbliss commented 10 months ago

I agree @hamishwillee, even if it is just adding the one extra step after forking main of making your own git tag, it should be mentioned.

julianoes commented 10 months ago

@hamishwillee It takes the version of PX4 from the last tag.

noahbliss commented 10 months ago

It doesn't though. If you fork main, then attempt the build process per the docs (which don't mention that you need to clone a tag or tag yourself), it fails. Presumably, following these directions (https://docs.px4.io/main/en/contribute/git_examples.html#contributing-code-to-px4) you would actually build your local instance of PX4 before/after committing to your own fork. The build process works if you have cloned PX4 from the PX4 repo directly, but if you fork, then clone, you need to tag. The docs say to fork then clone, so this caveat should be included in the docs in my opinion.

hamishwillee commented 10 months ago

@julianoes So you're saying that if you pull from the main repo you get the last tag, while if you pull from your own fork of the repo then you don't? Either way, that is broken given "how all docs on the internet tell you how to use git".

We could invert the instructions to fetch the main repo and define "downstream" but that's pretty ugly. Is there any other way to do this sanely?

julianoes commented 10 months ago

@bkueng might have an opinion.

The way I see it is that it's a fundamental drawback of depending on git and git tags in the build process.

noahbliss commented 10 months ago

If there was some way to detect if the branch is main and tag is null, default to building anyways with some kind of "dev" tag, could work.

dagar commented 10 months ago

I'd like to see it relaxed so it proceeds sanely (with a clear warning) if the tags aren't present.

mcsauder commented 10 months ago

I dont think its so terribly difficult for anyone for type git submodule update --init --recuresive

mcsauder commented 10 months ago

It does cause literal insanity until you learn that prompt, however.

hamishwillee commented 10 months ago

I dont think its so terribly difficult for anyone for type git submodule update --init --recursive

@mcsauder That would not solve the problem under discussion here.

I'd like to see it relaxed so it proceeds sanely (with a clear warning) if the tags aren't present.

@dagar That would be good. Warning and instruction how to fix it would work. Who's the best person to "assign" that task?