• Show log

    Commit

  • Hash : 8df4f519
    Author : Edward Thomson
    Date : 2020-05-23T15:04:54

    clar: copy files internally instead of /bin/cp clar has historically shelled out to `/bin/cp` to copy test fixtures into a sandbox. This has two deficiencies: 1. It's slower than simply opening the source and destination and copying them in a read/write loop. On my Mac, the `/bin/cp` based approach takes ~2:40 for a full test pass. Using a read/write loop to copy the files ourselves takes ~1:50. 2. It's noisy. Since the leak detector follows fork/exec, we'll end up running the leak detector on `/bin/cp`. This would be fine, except that the leak detector spams the console on startup and shutdown, so it adds a _lot_ of additional information to the test runs that is useless. By not forking and using this internal system, we see much less output.

  • README.md

  • Writing Clar tests for libgit2

    For information on the Clar testing framework and a detailed introduction please visit:

    https://github.com/vmg/clar

    • Write your modules and tests. Use good, meaningful names.

    • Make sure you actually build the tests by setting:

        cmake -DBUILD_CLAR=ON build/
    • Test:

        ./build/libgit2_clar
    • Make sure everything is fine.

    • Send your pull request. That’s it.

    Memory leak checks

    These are automatically run as part of CI, but if you want to check locally:

    Linux

    Uses valgrind:

    $ cmake -DBUILD_CLAR=ON -DVALGRIND=ON ..
    $ cmake --build .
    $ valgrind --leak-check=full --show-reachable=yes --num-callers=50 --suppressions=../libgit2_clar.supp \
      ./libgit2_clar

    macOS

    Uses leaks, which requires XCode installed:

    $ MallocStackLogging=1 MallocScribble=1 MallocLogFile=/dev/null CLAR_AT_EXIT="leaks -quiet \$PPID" \
      ./libgit2_clar