Fixed external library linking for Clang in VS2019+ #1522
Conversation
src/tools/clang.lua
Outdated
| @@ -282,7 +283,12 @@ | |||
| -- | |||
|
|
|||
| function clang.getlinks(cfg, systemonly, nogroups) | |||
| return gcc.getlinks(cfg, systemonly, nogroups) | |||
| -- For visual studio projects, the links should match the MSC convention | |||
There was a problem hiding this comment.
This is wrong, it should only apply to Windows projects, not all projects. Furthermore, this change should be made in the VS module.
There was a problem hiding this comment.
I can easily move the change to the VS module. Just so I go the agreed course of action, would you say:
- Changes made in the vs2019 module
- Changes only affect the clang and msc toolsets for windows projects
|
Not sure why the test is failing for macosx release on the response code test, especially since what I did shouldn't have affected that |
|
Huh, wonder what the issue with the last run was. Glad to see the release macosx build is working now, though. |
|
The HTTP unit tests connect to an external service, it's likely it was just a weird issue within the Azure network - I get this a lot at work with Azure Pipelines. |
Makes sense. Thanks for closing this out! |
What does this PR do?
Fixes problems referenced in #1520 and #1507 where the clang toolset produces a bad external library path when used with VS2019. Current behavior deferred the library generation to gcc's implementation, such that external libraries received the string "-lName" (e.g. "-lSDL") instead of "name.lib" (e.g. "SDL.lib").
How does this PR change Premake's behavior?
Changes the clang tool's
getlinksmethod to defer to MSC when the action is VS2019 or newer.Anything else we should know?
N/A
Did you check all the boxes?
closes #XXXXin comment to auto-close issue when PR is merged)You can now support Premake on our OpenCollective. Your contributions help us spend more time responding to requests like these!