Using the system's curl gives us access to an ssl-enabled curl library,
which is important as CMake will not be able to download assets from
GitHub and other sites that host them via https without ssl support. An
alternative, would be to build with "-- -DCMAKE_USE_OPENSSL=ON" instead,
as CMake doesn't enable ssl support by default with its bundled libcurl.
Also, enable the system zlib and bzip2 at the recommendation of
@mikemcquaid.
ClosesHomebrew/homebrew#38147.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
Can cause hard-to-debug errors and I'm not sure what the advantage is
of using our own versions, really.
ClosesHomebrew/homebrew#37770.
ClosesHomebrew/homebrew#37987.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
Update cmake formula to 3.2.1.
The newest cmake picks up a system jsoncpp installation by default, so
using the argument --no-system-jsoncpp is necessary to keep system
dependencies the same as before.
ClosesHomebrew/homebrew#37686.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
Seems pretty much every CMake project that uses SSL is using the same
broken code for finding OpenSSL. Welp. Including CMake themselves.
Double welp.
This is the upstream patch that will be in the next release, and is in
the HEAD already.
ClosesHomebrew/homebrew#36361.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
The GUI option is potentially a cause of future headaches and bugs, see
Per Mike’s proposal, which I agree with, we could ditch it and move
back to supporting the CLI tools only, and nudge people towards using
the Cask for the app. The Cask very kindly merged my PR to create `
CMake.app ` this morning in
https://github.com/caskroom/homebrew-cask/commit/3db9c980adc2be2a7d6b161
a95cc8c24a6d82fca so ` brew cask install cmake ` will now result in
that.
ClosesHomebrew/homebrew#35463.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
