Re: [Check-devel] Housekeeping ideas

[Hrvoje V. <hrv...@gm...>]

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...https://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
>