It turns out that variables have function scope by default. Let's
really set -liconv and add a few libraries that were forgotten in
the previous commit.
We also need to special-case OSX, as they ship zlib but do not provide
a pkg-config file for it.
When linking statically, the including project needs to know what the
current library build depends on so they can link to it. Store this
information in the pkg-config file.
While here, remove claims that users need to link to zlib or libcrypto.
Before these changes, looking up a reference would return the
same precomposed or decomposed form of the reference name that
was used to look it up, so on MacOS which ignores the difference
between the two, a single reference could be looked up either way
and git_reference_name would return the form of the name that was
used to look it up! This change makes lookup always return the
precomposed name if core.precomposeunicode is set regardless of
which version was used to look it up. The reference iterator was
already returning the precomposed form from earlier work.
This also updates the CMakeLists.txt rules for enabling iconv
usage because the clar tests for this code were actually not being
activated properly with the old version.
Finally, this moves git_repository_reset_filesystem from include/
git2/repository.h to include/git2/sys/repository.h since it is not
really a function that normal library users should have to think
about very often.
This hooks up git_path_direach and git_path_dirload so that they
will take a flag indicating if directory entry names should be
tested and converted from decomposed unicode to precomposed form.
This code will only come into play on the Apple platform and even
then, only when certain types of filesystems are used.
This involved adding a flag to these functions which involved
changing a lot of places in the code.
This was an opportunity to do a bit of code cleanup here and there,
for example, getting rid of the git_futils_cleanupdir_r function in
favor of a simple flag to git_futils_rmdir_r to not remove the top
level entry. That ended up adding depth tracking during rmdir_r
which led to a safety check for infinite directory recursion. Yay.
This hasn't actually been tested on the Mac filesystems where the
issue occurs. I still need to get test environment for that.
This adds the basics of progress reporting during push. While progress
for all aspects of a push operation are not reported with this change,
it lays the foundation to add these later. Push progress reporting
can be improved in the future - and consumers of the API should
just get more accurate information at that point.
The main areas where this is lacking are:
1) packbuilding progress: does not report progress during deltafication,
as this involves coordinating progress from multiple threads.
2) network progress: reports progress as objects and bytes are going
to be written to the subtransport (instead of as client gets
confirmation that they have been received by the server) and leaves
out some of the bytes that are transfered as part of the push protocol.
Basically, this reports the pack bytes that are written to the
subtransport. It does not report the bytes sent on the wire that
are received by the server. This should be a good estimate of
progress (and an improvement over no progress).
Set up the ssh credentials so we are able to talk to localhost and
issue git commands. Move to use a script, as the command list is
getting somewhat long.
While here, delay installing valgrind until we need it, as it and its
dependencies are by far the largest downloads and this allows us to
start compiling (and failing) faster and we only incur this cost when
the test suite runs successfully.
With the current code, running 'cmake .' in an already-configured
directory causes the removal of ssh flags passed to the compiler,
making it impossible to build with ssh support but by removing CMake's
cache.
Remove the check for LIBSSH2_LIBRARY and let CMake do the right thing
wrt finding the library.
Create a new section of clar tests "stress" that will default to
being off where we can put slow tests that push the library for
performance testing purposes.
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.
If it's not available, an error saying so will be returned when trying
to use a https:// URL.
This also unifies a lot of the network code to use git_transport in
many places instead of an socket descriptor.
Since Solaris does not support some of the same flags as glibc fnmatch(),
we just use the implementation we have for Windows.
Now that it's no longer a windows-specific thing, I moved it into compat/
instead of win32/
Previously, it was defined in netops.c, but it's also needed in one of the
clar tests, so I figured we might as well just make it global for the
whole project.
Without it, the mingw32 linker won't resolve GetProcessId() (called from
the core/errors.c clar test) because of some conditionals in windows.h.
Created a copy of tests/resources/testrepo.git that is compatible
with the Clar sandboxing helpers.
Restructured commit test suites to use Clar sandbox helpers.
Now using typed data arrays rather than lots of macros to define test
cases.
The clay test suite files clay.h and clay_main.c are generated by
the clay python script. Teach CMake about this dependency and
remove the generated files from the repository.
Update all stack allocations of git_filebuf to use GIT_FILEBUF_INIT
and make git_filebuf_open and git_filebuf_cleanup safe to be called
multiple times on the same buffer.
Signed-off-by: Vicent Marti <tanoku@gmail.com>
If either CFLAGS is defined or the user passes -DCMAKE_C_FLAGS to
cmake, the variable already contains flags. Don't overwrite them, but
append them to our settings.
Signed-off-by: Carlos Martín Nieto <carlos@cmartin.tk>
In libgit2: Move an enum out of an int bitfield in the HTTP transport.
In the parser: Use int bitfields and change some variable sizes to
better fit thir use. Variables that count the size of the data chunk
can only ever be as large as off_t. Warning 4127 can be ignored, as
nobody takes it seriously anyway.
From Emeric: change some variable declarations to keep MSVC happy.
Signed-off-by: Carlos Martín Nieto <carlos@cmartin.tk>
