Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@MrsTonedOne
Copy link
Contributor

also made it skip empty lines because they sometimes randomly get printed in the middle of runtime messages

also made it skip empty lines because they sometimes randomly get printed in the middle of runtime messages
@tgstation-server tgstation-server added the Tools We pretend to be a real development community label Dec 4, 2020
Cyberboss
Cyberboss previously approved these changes Dec 5, 2020
Copy link
Member

@Cyberboss Cyberboss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WHY IS THERE CPP IN THIS REPO THAT I'M JUST NOW LEARNING OF.

CAN 2020 GET ANY WORSE?

@Cyberboss
Copy link
Member

THANK YOU UNIVERSE, YOU'RE A PAL
image

Copy link
Contributor

@SpaceManiac SpaceManiac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a pressing need to keep the .exe in the tree? I'd rather delete the binary than continue to bloat the Git repository. Could add a build script or something if that would help in return

@MrsTonedOne
Copy link
Contributor Author

That would, and could, be solved by removing it from this repo and moving it over to its own repo where we can use the release tab to handle the binaries.

This is the tools folder, not the tools-src folder, it should have binaries for tools that need binaries to run.

@MrsTonedOne
Copy link
Contributor Author

I'm thinking in the terms of a dev who wants to use this tool to handle a 1gb runtime file on their latest change that had like 50 different looping runtimes, so they can actually open it and see the runtime errors. There needs to be a binary published somewhere for that.

(As that exact situation is how i even found out about the tool in the first place.)

@SpaceManiac
Copy link
Contributor

Repost of what I wrote in Discord:

If you were putting precompiled .exes in their own repo, it would still be stupid, because that's not what Git is for, but it would bother me less because it's somewhere else. I have no problem keeping the source code to the tools in the main repo.

If you really need "official" precompiled .exes available, CI artifacts should be made to serve that purpose

I think I can find a way to accomplish all of:

  1. Source code stays in the main repo
  2. Binary .exes are available in a convenient location
  3. Compile outputs aren't committed into Git

@MrsTonedOne
Copy link
Contributor Author

MrsTonedOne commented Dec 12, 2020

The only way to achieve that that makes sense is to move runtime condenser to it own repo and use the release tab for binaries.

Building a CD/CI pipeline for a program that averages 0.5 changes a year makes no sense when releases can be manually managed via the github tab.

@SpaceManiac
Copy link
Contributor

I suppose arguing (separate repo's Releases or CI/CD) vs. (this repo's Releases or CI/CD) is mostly a matter of preference at this point - either one would solve my grievance which is with compile outputs committed to Git. But we do have 4 tools that probably don't deserve to become four entire repos:

  • tools/Runtime Condenser/RuntimeCondenser.exe
  • tools/dmifonts/DmiFonts.exe
  • tools/CreditsTool/CreditsTool.exe
  • tools/DM Line counter.exe (actually I think we don't have source for this one?)

@SpaceManiac
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Tools We pretend to be a real development community

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants