Added ability to use system curl
What does this PR do?
This PR introduces the --curl-src option which deprecates --no-curl (for backwards compatibility), this new option allows users to pick between:
none, replaces--no-curlcontrib, default and what is currently usedsystem, the system library
In addition to this new option, the Linux builds will test all three options to ensure unit tests continue to work and don't have issues with the settings.
How does this PR change Premake's behavior?
Users can still build with --no-curl but it will warn and prompt users to migrate to --curl-src=none.
The core focus of this PR was to allow users to build Premake with their system curl instead.
Anything else we should know?
Various unit tests, specifically Nuget tests, weren't properly checking for the http. This check has been added so the builds continue to work.
Did you check all the boxes?
- [x] Focus on a single fix or feature; remove any unrelated formatting or code changes
- [x] Add unit tests showing fix or feature works; all tests pass
- [ ] 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
- [x] 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!
We may want to update the message from https://github.com/premake/premake-core/blob/master/modules/vstudio/vs2010_nuget.lua#L413 as well.
We may want to update the message from https://github.com/premake/premake-core/blob/master/modules/vstudio/vs2010_nuget.lua#L413 as well.
Good catch, I forgot to search the codebase for references to --no-curl.
This feels like a good idea to allow for usage of the host's curl.
Is this one ready to merge?
@tritao : there is at least conflicts to resolve.