Add TCC support
What does this PR do?
Add's TCC support
How does this PR change Premake's behavior?
Add's TCC support
Anything else we should know?
Needs review and tests (?)
Did you check all the boxes?
- [x] Focus on a single fix or feature; remove any unrelated formatting or code changes
- [ ] Add unit tests showing fix or feature works; all tests pass
- [x] Mention any related issues (put
closes #XXXXin comment to auto-close issue when PR is merged) - [x] Follow our coding conventions
- [x] Minimize the number of commits
- [ ] Align documentation to your changes
You can now support Premake on our OpenCollective. Your contributions help us spend more time responding to requests like these!
bumps #350
I like TCC for testing (smaller) programs due to it's incredible speed, so that is why I made this PR
FYI: This is using maintained fork of TCC
I still need to test more options this weekend bare in mind
The issue I'd have with adding in TCC to core is that the core team doesn't use TCC thus doesn't have the expertise to maintain it (one of the issues with the D stuff right now). Is it possible to make this a plugin/external script at least initially?
D module seems written in modular way though. You might use D as model to write premake-tcc as external module.
The issue I'd have with adding in TCC to core is that the core team doesn't use TCC thus doesn't have the expertise to maintain it (one of the issues with the D stuff right now). Is it possible to make this a plugin/external script at least initially?
I'm willing to maintain it myself, I use premake for many of my projects. If I have to stand up to maintain something it shouldn't be difficult
The issue I'd have with adding in TCC to core is that the core team doesn't use TCC thus doesn't have the expertise to maintain it (one of the issues with the D stuff right now). Is it possible to make this a plugin/external script at least initially?
I'm willing to maintain it myself, I use premake for many of my projects. If I have to stand up to maintain something it shouldn't be difficult
Agreed that it shouldn't be difficult. It's why external scripts are intentionally as pain-free as possible. We've recently had a similar discussion on a PR of NVCC into the core repository. It's a hard balance to strike with adding new exporters and toolsets, as there's only half a dozen people actively working on the repo, usually no more than 1 or 2 at a time (this doesn't count those who send in the one off PRs, for which we are extremely appreciative of).
Would like to see @samsinsane and @starkos's thoughts on this as well.
Hi, regardless of conflicts I would like to bump this. Any thoughts?
I personally hold the same stance, but commentary from other maintainers would be appreciated.