b53671a (Search for zlib unconditional, 2012-12-18) changed things
around to always (even on windows, that's what the subject refers to)
call FIND_PACKAGE(ZLIB).
However, it did not correctly handle the case where ZLIB_LIBRARY is
cached, either by the user setting it manually or by an earlier
search. In that case, the IF(ZLIB_FOUND) would not trigger (that
variable is not cached) and we'd instead use the built-in version.
000e689 (CMake: don't try to use bundled zlib when the system's path
is in the cache, 2013-05-12) tried to fix that, but it actually made
the problem worse: now with ZLIB_LIBRARY cached, _neither_ of the
blocks would execute, resulting in a linker error for me when trying
to build such a doubly-configured setup.
To fix the issue, we just trust CMake to do the right thing. If
ZLIB_LIBRARY is set (either from user or cache) then the find_library
in FindZLIB.cmake will use that instead of searching again. So we can
unconditionally (for real this time) call FIND_PACKAGE(ZLIB), and just
check its result.
The code surrounding zlib bundling did not take into consideration
that ZLIB_LIBRARY gets cached, and assumed that FIND(ZLIB) would
always set ZLIB_FOUND, which does not hold true, as this variable
signifies that we have found the package and had to look at the
system, as its location was not cached.
Only use the bundled sources if the external zlib is neither
newly-found nor cached.
Up to now, on windows we don't even bother to look if the user has a zlib
available somwhere.
In almost all larger commercial projects i've participated in, it was not
at all uncommon to have such a dependency somewhere in the source tree and
use it whereever required.
Searching for it, even if it's unlikely to be present, allows for such a
scenario (i.e. by prefilling the CMake-Cache).
My other PR revealed, that the /W4 parameter, we give to MSVC is ignored
because cmake set CMAKE_C_FLAGS already to /W3 and we overwrite it.
The command line tools gave me a D9025 warning for this on every file and
looking into the project properties page on MSVC 2008 tells, that it has
the warning level set to /W3.
However, the warnings introduced by /W4 are far to useless for having
them enabled. So just disable them.
The reason, why libgit2 currently cannot support compiling via the command-line
tools cl/nmake from WinSDK and/or Microsoft Visual Studio, seems to be a
missing dependency on the generated precompiled header file.
The Visual Studio IDE automatically inserts this dependency when it sees the
right combination of "/Y" parameters.
This patch allows to compile using command line tools by disabling precompiled
headers for NON-IDE builds.
libcryto's SHA-1 implementation is measurably better than the one that
ships with the library. If we link to it for HTTPS support already,
use that implementation instead.
Testing on a ~600MB of the linux repository, this reduces indexing
time by 40% and removes the hashing from the top spot in the perf
output.
Rename INSTALL_INC and INSTALL_BIN to INCLUDE_INSTALL_DIR and
BIN_INSTALL_DIR, which are more commonly used. This is also
consistent with the variable for the library path which is
already LIB_INSTALL_DIR.
Wondows has its own HTTP library. Use that one when possible instead of
our own.
As we don't depend on them anymore, remove the http-parser library from
the Windows build, as well as the search for OpenSSL.
Needs AmigaOS.cmake now from CMake package at OS4Depot, or contents below:
--8<--
SET(AMIGA 1)
SET(CMAKE_SHARED_LIBRARY_C_FLAGS "-fPIC")
SET(CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS "-shared")
--8<--
t to use openssl, as confusing cross-compiler
t to use openssl, as confusing cross-compiler
ss
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: CMakeLists.txt
Two things:
1) By default, Linux CMake puts -fPIC on the link line. So we remove that
for MINGW to avoid warnings that it will be ignored.
2) Similarly, move -fvisibility=hidden flag to be for non-mingw
compilation only to avoid warnings that it will be ignored.
