Added ability to use system zlib#2355
Conversation
| end | ||
| filter { "options:zlib-src=system" } | ||
| links { "zip", "z" } | ||
| filter {} |
There was a problem hiding this comment.
| filter {} |
There is another filter just after.
There was a problem hiding this comment.
(Maybe?) Hot take: I like having filters closed after, before opening up another.
There was a problem hiding this comment.
Consistency with other
either
filter A
-- ..
filter {}
filter B
-- ..
filter {}
filter C
-- ..
filter {}
filter D
-- ..
filter{}
or
filter A
-- ..
filter B
-- ..
filter C
-- ..
filter D
-- ..
filter{}
There was a problem hiding this comment.
Yeah, let's get it consistent first :)
There was a problem hiding this comment.
FWIW, I went for consistency with the block below which required the filter{}. My goal for both blocks was to reduce the changes as much as possible. I was intending to follow up all these changes with another PR to cleanup this up and the premake5.lua scripts in general (if there's anything else to clean up).
I can fix it now if you guys would prefer?
There was a problem hiding this comment.
If we go for a cleanup PR after, I'm happy either way.
e8a898d to
33f231a
Compare
What does this PR do?
This PR introduces the
--zlib-srcoption which deprecates--no-zlib(for backwards compatibility), this new option allows users to pick between:none, replaces--no-zlibcontrib, default and what is currently usedsystem, the system libraryHow does this PR change Premake's behavior?
Users can still build with
--no-zlibbut it will warn and prompt users to migrate to--zlib-src=none.The core focus of this PR was to allow users to build Premake with their system zlib instead.
Anything else we should know?
Due to spaces in
PREMAKE_OPTSsome minor changes toBootstrap.shwere needed to avoid errors.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!