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

Fix: CPack source package creation #8197

Closed
wants to merge 1 commit into from

Conversation

@frosch123
Copy link
Member

@frosch123 frosch123 commented Jun 6, 2020

This does not work as I would like it to:

  • "package_source" does not depend on "find_version". Thus source bundles will be named wrong, unless a real build was run before. No idea how to fix this.
  • "package_source" only has a black-list, but otherwise it bundles all files in the working directory. This may include secret stuff, or whatever temporary files are there. So essentially unsuitable to run locally.
@glx22
Copy link
Contributor

@glx22 glx22 commented Jun 7, 2020

I see two possible options for "find_version":

  • add an execute_process with the same command as "find_version" target (but version can be wrong if any changes happen between cmake run and the next real build run) I tried, that doesn't work. So only option 2 I guess.
  • add a custom target which will depend on "find_version" and will then run "package_source". This option would also allow to generate a temporary .ottdrev just for source packaging

I confirm the second issue, but there's probably a way to fill CPACK_SOURCE_IGNORE_FILES with .gitignore content and some git ls-files magic.

@glx22
Copy link
Contributor

@glx22 glx22 commented Jun 8, 2020

I tried something on master...glx22:pr/8197
It seems to work, may need some tweaking.

@TrueBrain
Copy link
Member

@TrueBrain TrueBrain commented Dec 13, 2020

I like what you did @glx22 , as that ignores any non-git-committed-file, meaning it also picks up everything in .gitignore, which is really nice. It basically solves #2. And you solved #1 too. Would you mind dusting this off and pushing it either over @frosch123's branch (I don't know if he appreciates that, but I am sure it is fine :P) or make a new PR yourself?

Would be good to include this in the release-workflow PR we are working on :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants