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

Cloning the repo, pushing it elsewere and cloning again breaks the build process #563

Closed
2 tasks done
alexer opened this issue Mar 2, 2017 · 3 comments · Fixed by #762
Closed
2 tasks done

Cloning the repo, pushing it elsewere and cloning again breaks the build process #563

alexer opened this issue Mar 2, 2017 · 3 comments · Fixed by #762

Comments

@alexer
Copy link

alexer commented Mar 2, 2017

  • Operating system: Linux
  • Stlink tools version and/or git commit hash: latest/git-9d08810

Cloning the repository, pushing it to somewhere else, and cloning it from that second place breaks the build process.

Error from make:

CMake Error at CMakeLists.txt:91 (set_target_properties):
  set_target_properties called with incorrect number of arguments.

It seems to fail because some of the variables in

set_target_properties(${STLINK_LIB_SHARED}
        PROPERTIES SOVERSION ${PROJECT_VERSION_MAJOR}
        VERSION ${STLINK_SHARED_VERSION}
)

end up being empty, because cmake/Version.cmake tries to get the values with git describe which fails because it doesn't find any names, presumably because the tags aren't pushed by default.

Doing a git push --tags from a repo cloned directly from the official repository to the other repository, followed by git pull --tags in the non-working copy fixes this.

I suggest that in addition to checking that git exists and the project is under git, cmake/Version.cmake should also check that the repository actually contains any tags before taking the git-aware branch of the conditional.

@xor-gate
Copy link
Member

xor-gate commented Mar 3, 2017

The version detection uses git tags or ".version" file. It is possible this is broken, not tested in this scenario.

@xor-gate xor-gate added this to the Unplanned (Contributions Welcome) milestone Mar 3, 2017
@alexer
Copy link
Author

alexer commented Mar 3, 2017

Yeah, it uses git if it finds it and the project has a .git directory, but doesn't fall back to the .version file if the git method fails for some reason, be it due to lack of tags or something else.

@xor-gate
Copy link
Member

xor-gate commented Mar 3, 2017

It doesn't detect when no tags are present which causes the problem.

@Nightwalker-87 Nightwalker-87 modified the milestones: Unplanned (Contributions Welcome), Next Feb 19, 2020
@Nightwalker-87 Nightwalker-87 modified the milestones: General, v1.7.0, Feedback required Mar 14, 2020
@Nightwalker-87 Nightwalker-87 modified the milestones: Feedback required, v1.6.1 Apr 6, 2020
@Nightwalker-87 Nightwalker-87 changed the title Cloning the repo, pushing it elsewere and cloning again breaks the build process [install] Cloning the repo, pushing it elsewere and cloning again breaks the build process Apr 6, 2020
@Nightwalker-87 Nightwalker-87 modified the milestones: v1.6.1, v1.6.0 Apr 7, 2020
@Nightwalker-87 Nightwalker-87 changed the title [install] Cloning the repo, pushing it elsewere and cloning again breaks the build process Cloning the repo, pushing it elsewere and cloning again breaks the build process Apr 7, 2020
@Nightwalker-87 Nightwalker-87 self-assigned this Apr 7, 2020
@stlink-org stlink-org locked as resolved and limited conversation to collaborators Apr 14, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.