Re: [Check-devel] Housekeeping ideas

[Branden A. <b.m...@gm...>]

> I have a few ideas that I can contribute back to the project.

Welcome!


> Valgrind reports a lot of memory issues; leaks and invalid reads and
writes.
> My idea is to fix everything what can be fixed.

My recollection was that the failures which were found were due to the unit
test program creating forks (one for each unit test), and those unit tests
not "cleaning up" the memory from the parent before terminating. Those were
noise rather than finding issues, if I recall correctly. When the testing
program was created I did not find any invalid memory reads or writes, for
example. If there are any of those, they certainly should be fixed (:


> Continuing from the first one; maybe it is better if project uses just
one build system? If you guys agree with this, I propose that we keep using
GNU Autotools and ditch CMake since this is a "pure UNIX" software; Windows
users needs to install MinGW, MSYS or Cygwin.

I agree with Mikko. The project leverages CMake to support some Windows
toolchains which do not use Autotools. Checkout the docs on installing on
Windows for some examples:

https://libcheck.github.io/check/web/install.html


> Write a Dockerfile that can be used to build the project,...
> Integrate this Docker Container into Travis CI so that it can
automatically do all steps mentioned from the previous step.

The project currently uses GitHub Actions to run automated tests on Linux,
macOS, and Windows hosts. Over time the project has used a few different
platforms for testing, including Cloudbees (Jenkins), Travis CI, AppVeyor,
and GitHub Actions. As GitHub Actions now supports all three OSs that we
support, the testing has been migrated to Github Actions:

https://github.com/libcheck/check/tree/master/.github/workflows

That testing does not require creating a Docker image, as Github Actions
runs the tests in a container already. If you have ideas for how to improve
our testing strategy, let us know.

On Sun, Dec 27, 2020 at 5:57 AM Hrvoje Varga <hrv...@gm...> wrote:

> Thanks for the insights. I'll start with the housekeeping. :)
>
> Happy holidays guys!
>
> On Sat, Dec 26, 2020 at 5:01 PM Mikko Johannes Koivunalho <
> mik...@ik...> wrote:
>
>> Hello Hrvoje,
>>
>> Many good points. Thanks for taking them up. Just a few comments on some
>> of them.
>>
>> - check_mem_leaks
>>     Missing in CMake build. Some things are still missing in the CMake
>> build. And a few things could take more fine tuning, e.g. how we use
>> Subunit.
>>
>> - CMake
>>     Actually, we have been moving towards CMake for a while. CMake is
>> better supported in Windows and in Microsoft tools, e.g. Visual Studio.
>>
>> https://devblogs.microsoft.com/cppblog/cmake-support-in-visual-studio/
>>     CMake also supports using Check as a sub project of the main (CMake)
>> project, so you don't have to install libcheck into the system, which is
>> how you normally operate with GNU Autotools. CMake builds are used. Earlier
>> this year we fixed an issue in CMake configuration relating to this way of
>> using Check: https://github.com/libcheck/check/issues/238.
>>
>> - Valgrind
>>     There is still memory issues. If you can find and fix some of those,
>> it would great. Thanks.
>>
>> Cheers,
>> Mikko Koivunalho
>>
>> Merry Christmas and a Happy New Year!
>>
>>
>> On 2020-12-26 11:23, Hrvoje Varga wrote:
>>
>> Hi everyone,
>>
>> I am new to the project, both from user and dev perspective. In a couple
>> of days with playing around with the check, I have a few ideas that I can
>> contribute back to the project. Sorry if this was previously discussed.
>>
>>    1. It seems that check_mem_leaks is not part of the CMake build
>>    although it is integrated into GNU Autotools scripts. Integration into GNU
>>    Autotools scripts was done brarcher. See his commit
>>    8699473b65011b50766d536222329eeb3953f1cc:
>>
>>    commit 8699473b65011b50766d536222329eeb3953f1cc
>>    Author: brarcher <brarcher@64e312b2-a51f-0410-8e61-82d0ca0eb02a>
>>    Date:   Wed Dec 18 21:37:09 2013 +0000
>>
>>        check_mem_leaks: add new unit test for use against valgrind
>>
>>    I am not sure if that was intention. Is there a possibility that
>>    author forgot to include it into CMake scripts?
>>
>>    In any case, I have prepared a commit that adds check_mem_leaks to
>>    CMake scripts. I just haven't created a pull request.
>>    2. Continuing from the first one; maybe it is better if project uses
>>    just one build system? If you guys agree with this, I propose that we keep
>>    using GNU Autotools and ditch CMake since this is a "pure UNIX" software;
>>    Windows users needs to install MinGW, MSYS or Cygwin.
>>
>>    I strongly encourage only one build system, whichever the choice. I
>>    can prepare a commit for this if we can agree with this.
>>    3. Valgrind reports a lot of memory issues; leaks and invalid reads
>>    and writes.
>>    My idea is to fix everything what can be fixed.
>>    4. Write a Dockerfile that can be used to build the project, run
>>    tests including running Valgrind to check for memory errors, generate API
>>    documentation, and to have a static code analysis of the whole codebase.
>>    5. Integrate this Docker Container into Travis CI so that it can
>>    automatically do all steps mentioned from the previous step.
>>
>> I do apologies if I sound like I am trying to impose myself into the
>> project since I am a newbie to it. I just feel like I need to contribute my
>> know-how. Let me know what do you think about this. If you do agree about
>> any or all of the points above, I can create an issue for each individual
>> point so that we can track them.
>>
>> br,
>> Hrvoje
>>
>>
>> _______________________________________________
>> Check-devel mailing lis...@li...://lists.sourceforge.net/lists/listinfo/check-devel
>>
>>
>> --
>> Mikko Koivunalho
>> LinkedIn: http://www.linkedin.com/in/MikkoKoivunalho
>> AboutMe: http://about.me/mikkokoivunalho
>> Blog: http://www.koivunalho.org/blogs/exercises-in-integration-and-delivery/
>> [ This message has been signed with PGP. Public key attached. ]
>>
>> _______________________________________________
>> Check-devel mailing list
>> Che...@li...
>> https://lists.sourceforge.net/lists/listinfo/check-devel
>>
> _______________________________________________
> Check-devel mailing list
> Che...@li...
> https://lists.sourceforge.net/lists/listinfo/check-devel
>