Menu
▾
▴
check-devel
|
From: Hrvoje V. <hrv...@gm...> - 2020-12-26 10:24:10
|
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
|
|
From: Mikko J. K. <mik...@ik...> - 2020-12-26 16:01:40
Attachments:
signature.asc
0xA672AD0F974B77B8.asc
|
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 list > Che...@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. ] |
|
From: Hrvoje V. <hrv...@gm...> - 2020-12-27 13:57:47
|
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 > |
|
From: Branden A. <b.m...@gm...> - 2021-01-01 01:15:35
|
> 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...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 >> > _______________________________________________ > Check-devel mailing list > Che...@li... > https://lists.sourceforge.net/lists/listinfo/check-devel > |
Thanks for helping keep SourceForge clean.
X