From nilsgladitz at gmail.com Wed Apr 1 10:05:42 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 01 Apr 2015 16:05:42 +0200 Subject: [Cdash] Emma coverage In-Reply-To: References: <551A6F12.6030709@gmail.com> <551AE641.1090304@gmail.com> Message-ID: <551BFB36.60000@gmail.com> On 31.03.2015 20:41, Zack Galbreath wrote: > > https://gitlab.kitware.com/zackgalbreath/emma/commit/ac808cc7cdc90d1f6db8dcee96812e088fd17066 > Yes, it looks like it does apply on top of the emma release and the gwt patch that we were using: https://github.com/ngladitz/emma I can also verify that it generates the .json files. Thanks! I still have to look into how I'll run all this from the ctest client script rather than the project itself. Maybe it would make sense to mirror the package hierarchy for the .json output files to disambiguate in case there are multiple classes sharing the same name in different packages? Or is there already some other mechanism that I am overlooking? Nils From nilsgladitz at gmail.com Thu Apr 2 05:03:30 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 02 Apr 2015 11:03:30 +0200 Subject: [Cdash] Excluding sources from GcovTar coverage Message-ID: <551D05E2.8070305@gmail.com> I am looking into replacing ctest_coverage() with CMake's new CTestCoverageCollectGCOV module and CDash's new GcovTar coverage support. Is there an existing way to reproduce what ctest_coverage() did with CTEST_CUSTOM_COVERAGE_EXCLUDE? If there isn't, where would be the best place to implement something like it? e.g should CTestCoverageCollectGCOV exclude coverage files from the tar or should CDash ignore them? For the later case how would one inform CDash about the inclusion? An additional/existing json configuration file in the tar? Nils From nilsgladitz at gmail.com Thu Apr 2 11:04:47 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 02 Apr 2015 17:04:47 +0200 Subject: [Cdash] Excluding sources from GcovTar coverage In-Reply-To: <551D05E2.8070305@gmail.com> References: <551D05E2.8070305@gmail.com> Message-ID: <551D5A8F.1040604@gmail.com> On 04/02/2015 11:03 AM, Nils Gladitz wrote: > I am looking into replacing ctest_coverage() with CMake's new > CTestCoverageCollectGCOV module and CDash's new GcovTar coverage support. > > Is there an existing way to reproduce what ctest_coverage() did with > CTEST_CUSTOM_COVERAGE_EXCLUDE? This seems to work for me: https://github.com/ngladitz/cmake/commit/2cfcdd2b870025d776d0b5c246764f09594bdc34 Nils From bill.hoffman at kitware.com Thu Apr 2 12:51:19 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 02 Apr 2015 12:51:19 -0400 Subject: [Cdash] Excluding sources from GcovTar coverage In-Reply-To: <551D5A8F.1040604@gmail.com> References: <551D05E2.8070305@gmail.com> <551D5A8F.1040604@gmail.com> Message-ID: <551D7387.3050603@kitware.com> On 4/2/2015 11:04 AM, Nils Gladitz wrote: >> Is there an existing way to reproduce what ctest_coverage() did with >> CTEST_CUSTOM_COVERAGE_EXCLUDE? > > This seems to work for me: > https://github.com/ngladitz/cmake/commit/2cfcdd2b870025d776d0b5c246764f09594bdc34 > > > Nils That looks good to me. You should push it to CMake. I guess the test (CTestCoverageCollectGCOV) should be updated to include this somehow, but it was an oversight, and should be added. Thanks. -Bill From clinton at elemtech.com Fri Apr 3 00:13:35 2015 From: clinton at elemtech.com (clinton at elemtech.com) Date: Thu, 2 Apr 2015 22:13:35 -0600 (MDT) Subject: [Cdash] cdash backup directory not being cleaned up In-Reply-To: <5516F821.4080503@kitware.com> References: <1527052.O2EkId6Hhb@stryke> <5516F821.4080503@kitware.com> Message-ID: <907569729.9376271.1428034415680.JavaMail.zimbra@elemtech.com> I found out why this wasn't working for me. Its related to my apache setup putting cdash on a virtual host. In cdash/do_submit.php, I can fix this by changing the if(function_exists("curl_init") == TRUE) { $currentURI = get_server_URI(true); ... } to if(function_exists("curl_init") == TRUE) { $currentURI = get_server_URI(false); ... } Alternatively, I can change to $CDASH_CURL_REQUEST_LOCALHOST='0'; in the config. If the intent of the setting is to account for virtual hosts, its not obvious from the comments nor from the name of the variable. Nor is it obvious what the interaction is between these settings: $CDASH_CURL_REQUEST_LOCALHOST='0'; $CDASH_CURL_LOCALHOST_PREFIX=''; $CDASH_BASE_URL=''; I first tried setting CDASH_BASE_URL, but that had no effect. So anyway, for now I have $CDASH_CURL_REQUEST_LOCALHOST='0'; because I see several places where get_server_URI(true) is called. Clint ----- Original Message ----- > Dave, Clinton, > > I'm guessing the asynchronous call is not working properly. > Are you getting daily file changed at the top of the dashboard? > > Can you try to call the dailyupdates directly from your browser? > Something like: > > http://localhost/CDash/cdash/dailyupdatescurl.php?projectid=1 > > with the projectid being the id of your project. > > Let me know if that works (or not), > Julien > > On 27/03/2015 19:50, David Cole via Cdash wrote: > > Ah ha! I just checked mine, and I have 3.8 G worth of *.xml files > > dating all the way back to May 22, 2013 in my backup folder: the week > > that I set it up... > > > > I have this in my config.local.php, intending to keep things around for a > > week: > > $CDASH_BACKUP_TIMEFRAME = '168'; // in hours > > > > Good thing it's not a high-volume CDash server! > > > > Looking forward to a fix for this one. ;-) > > > > > > > > On Fri, Mar 27, 2015 at 1:19 PM, Clinton Stimpson > > wrote: > >> Hi, > >> > >> I have another problem with cdash. > >> > >> The backup directory contains the submitted .xml files. > >> I have in my cdash/config.php file > >> $CDASH_BACKUP_TIMEFRAME = '48'; // 48 hours > >> > >> According to this, the .xml files older than 48 hours are supposed to be > >> cleaned up when new submissions arrive. > >> http://www.vtk.org/Wiki/CDash:Administration#Backup_mechanism > >> > >> This is not the case for me. My backup directory is accumulating and > >> contains > >> files from the distant past. Much more than 48 hours ago. > >> > >> Is anyone else seeing this, or could it be specific to my setup? > >> For example, I install cdash in a version specific folder, and then make a > >> softlink for apache. I don't know if something like that would prevent > >> the > >> cleanup. Permissions shouldn't be a problem because apache can put the > >> files > >> there, so it should be able to remove them. > >> > >> Clint > >> _______________________________________________ > >> Cdash mailing list > >> Cdash at public.kitware.com > >> http://public.kitware.com/mailman/listinfo/cdash > > _______________________________________________ > > Cdash mailing list > > Cdash at public.kitware.com > > http://public.kitware.com/mailman/listinfo/cdash > > > From nilsgladitz at gmail.com Fri Apr 3 06:14:49 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 03 Apr 2015 12:14:49 +0200 Subject: [Cdash] Excluding sources from GcovTar coverage In-Reply-To: <551D7387.3050603@kitware.com> References: <551D05E2.8070305@gmail.com> <551D5A8F.1040604@gmail.com> <551D7387.3050603@kitware.com> Message-ID: <551E6819.8050308@gmail.com> On 02.04.2015 18:51, Bill Hoffman wrote: > On 4/2/2015 11:04 AM, Nils Gladitz wrote: >> >> This seems to work for me: >> https://github.com/ngladitz/cmake/commit/2cfcdd2b870025d776d0b5c246764f09594bdc34 >> >> >> >> Nils > That looks good to me. You should push it to CMake. I guess the > test (CTestCoverageCollectGCOV) should be updated to include this > somehow, but it was an oversight, and should be added. > Thanks! I incorporated your break() suggestion, extended the test case and merged to next for testing. Nils From zack.galbreath at kitware.com Fri Apr 10 11:32:36 2015 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Fri, 10 Apr 2015 11:32:36 -0400 Subject: [Cdash] Emma coverage In-Reply-To: <551BFB36.60000@gmail.com> References: <551A6F12.6030709@gmail.com> <551AE641.1090304@gmail.com> <551BFB36.60000@gmail.com> Message-ID: On Wed, Apr 1, 2015 at 10:05 AM, Nils Gladitz wrote: > I still have to look into how I'll run all this from the ctest client > script rather than the project itself. > Locally I'm doing something very similar to CTestCoverageCollectGCOV, but this hasn't made it into CMake/Modules yet. > Maybe it would make sense to mirror the package hierarchy for the .json > output files to disambiguate in case there are multiple classes sharing the > same name in different packages? > Or is there already some other mechanism that I am overlooking? > The .json files should contain the package of the class. This is what CDash uses to report the coverage, as opposed to the per-directory view that it uses for gcov. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Apr 10 11:37:47 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 10 Apr 2015 17:37:47 +0200 Subject: [Cdash] Emma coverage In-Reply-To: References: <551A6F12.6030709@gmail.com> <551AE641.1090304@gmail.com> <551BFB36.60000@gmail.com> Message-ID: <5527EE4B.7090207@gmail.com> On 10.04.2015 17:32, Zack Galbreath wrote: > > On Wed, Apr 1, 2015 at 10:05 AM, Nils Gladitz > wrote: > > I still have to look into how I'll run all this from the ctest > client script rather than the project itself. > > > Locally I'm doing something very similar to CTestCoverageCollectGCOV, > but this hasn't made it into CMake/Modules yet. > Yes that is what I got too now. > Maybe it would make sense to mirror the package hierarchy for the > .json output files to disambiguate in case there are multiple > classes sharing the same name in different packages? > Or is there already some other mechanism that I am overlooking? > > > The .json files should contain the package of the class. This is what > CDash uses to report the coverage, as opposed to the per-directory > view that it uses for gcov. Doesn't that break though if there are two classes with the same name in two distinct packages? Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From zack.galbreath at kitware.com Fri Apr 10 11:55:46 2015 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Fri, 10 Apr 2015 11:55:46 -0400 Subject: [Cdash] Emma coverage In-Reply-To: <5527EE4B.7090207@gmail.com> References: <551A6F12.6030709@gmail.com> <551AE641.1090304@gmail.com> <551BFB36.60000@gmail.com> <5527EE4B.7090207@gmail.com> Message-ID: On Fri, Apr 10, 2015 at 11:37 AM, Nils Gladitz wrote: > The .json files should contain the package of the class. This is what > CDash uses to report the coverage, as opposed to the per-directory view > that it uses for gcov. > > > Doesn't that break though if there are two classes with the same name in > two distinct packages? After looking more closely I think you're right. We should probably incorporate the package name into $path for each file: https://github.com/Kitware/CDash/blob/master/xml_handlers/JavaJSONTar_handler.php#L164-L167 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Apr 10 12:02:31 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 10 Apr 2015 18:02:31 +0200 Subject: [Cdash] Emma coverage In-Reply-To: References: <551A6F12.6030709@gmail.com> <551AE641.1090304@gmail.com> <551BFB36.60000@gmail.com> <5527EE4B.7090207@gmail.com> Message-ID: <5527F417.5050809@gmail.com> On 10.04.2015 17:55, Zack Galbreath wrote: > On Fri, Apr 10, 2015 at 11:37 AM, Nils Gladitz > wrote: > >> The .json files should contain the package of the class. This is >> what CDash uses to report the coverage, as opposed to the >> per-directory view that it uses for gcov. > > Doesn't that break though if there are two classes with the same > name in two distinct packages? > > > > After looking more closely I think you're right. We should probably > incorporate the package name into $path for each file: > > https://github.com/Kitware/CDash/blob/master/xml_handlers/JavaJSONTar_handler.php#L164-L167 I mean wouldn't emma currently try to generate the same .json file for both classes? Since even though they are in different packages they would currently have the same .java.json filename written into the same output directory. Hence one overwriting the other and the former being lost? Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From zack.galbreath at kitware.com Fri Apr 10 12:43:47 2015 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Fri, 10 Apr 2015 12:43:47 -0400 Subject: [Cdash] Emma coverage In-Reply-To: <5527F417.5050809@gmail.com> References: <551A6F12.6030709@gmail.com> <551AE641.1090304@gmail.com> <551BFB36.60000@gmail.com> <5527EE4B.7090207@gmail.com> <5527F417.5050809@gmail.com> Message-ID: On Fri, Apr 10, 2015 at 12:02 PM, Nils Gladitz wrote: > I mean wouldn't emma currently try to generate the same .json file for > both classes? > Since even though they are in different packages they would currently have > the same .java.json filename written into the same output directory. > > Hence one overwriting the other and the former being lost? > That makes sense too. I guess we'll have to do something a bit more careful on the Java side. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Apr 10 14:08:54 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 10 Apr 2015 20:08:54 +0200 Subject: [Cdash] Emma coverage In-Reply-To: References: <551A6F12.6030709@gmail.com> <551AE641.1090304@gmail.com> <551BFB36.60000@gmail.com> <5527EE4B.7090207@gmail.com> <5527F417.5050809@gmail.com> Message-ID: <552811B6.4010106@gmail.com> On 10.04.2015 18:43, Zack Galbreath wrote: > On Fri, Apr 10, 2015 at 12:02 PM, Nils Gladitz > wrote: > > I mean wouldn't emma currently try to generate the same .json file > for both classes? > Since even though they are in different packages they would > currently have the same .java.json filename written into > the same output directory. > > Hence one overwriting the other and the former being lost? > > > > That makes sense too. I guess we'll have to do something a bit more > careful on the Java side. Does this look sensible? https://github.com/ngladitz/emma/commit/cba7bad1be36d5e135f2bd02f498d35943562801 I hope it isn't too obvious that I don't do much java :) Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Mon Apr 13 04:29:30 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 13 Apr 2015 10:29:30 +0200 Subject: [Cdash] Allow multiple coverage submissions for the same buildid Message-ID: <552B7E6A.9040300@gmail.com> I am trying to submit both gcov and java emma coverage from the same build which I think leads to: SQL error: ERROR: duplicate key value violates unique constraint "coveragesummary_pkey" Would it be possible to add a column to the coveragesummary table for the coverage type (e.g. gcov, emma) and make it part of the primary key so that multiple coverage submissions of different type become valid? Would any other changes be required to make this work? Nils From DLRdave at aol.com Mon Apr 13 06:35:05 2015 From: DLRdave at aol.com (David Cole) Date: Mon, 13 Apr 2015 06:35:05 -0400 Subject: [Cdash] Allow multiple coverage submissions for the same buildid In-Reply-To: <552B7E6A.9040300@gmail.com> References: <552B7E6A.9040300@gmail.com> Message-ID: Why not simply submit another build with the second coverage type (and a different build name)? I think you'll also need to decide how to handle multiple coverage types from the link on top level page, and on the coverage summary page itself. (Either links to multiple summaries, or a summary that takes into account multiple types.) Certainly more work than simply adding to the primary key... On Mon, Apr 13, 2015 at 4:29 AM, Nils Gladitz wrote: > I am trying to submit both gcov and java emma coverage from the same build > which I think leads to: > > SQL error: ERROR: duplicate key value violates unique constraint > "coveragesummary_pkey" > > Would it be possible to add a column to the coveragesummary table for the > coverage type (e.g. gcov, emma) and make it part of the primary key so that > multiple coverage submissions of different type become valid? > > Would any other changes be required to make this work? > > Nils > _______________________________________________ > Cdash mailing list > Cdash at public.kitware.com > http://public.kitware.com/mailman/listinfo/cdash From nilsgladitz at gmail.com Mon Apr 13 06:47:33 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 13 Apr 2015 12:47:33 +0200 Subject: [Cdash] Allow multiple coverage submissions for the same buildid In-Reply-To: References: <552B7E6A.9040300@gmail.com> Message-ID: <552B9EC5.5030700@gmail.com> On 04/13/2015 12:35 PM, David Cole wrote: > Why not simply submit another build with the second coverage type (and > a different build name)? That sounds good too. How would I go about implementing this? Can this be done from a single ctest job script run or would I have to run it once for each buildid? I assume it would involve more than e.g.: set(CTEST_BUILD_NAME "${CTEST_BUILD_NAME}-emma") ctest_submit(CDASH_UPLOAD ... CDASH_UPLOAD_TYPE JavaJSONTar) ? > I think you'll also need to decide how to handle multiple coverage > types from the link on top level page, and on the coverage summary > page itself. (Either links to multiple summaries, or a summary that > takes into account multiple types.) > > Certainly more work than simply adding to the primary key... I was thinking separate summaries like I would get from distinct builds. If I can submit just the emma coverage under a new buildid that would basically be what I want. Nils From nilsgladitz at gmail.com Tue Apr 14 08:30:42 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 14 Apr 2015 14:30:42 +0200 Subject: [Cdash] buildfile cache and json tar issues Message-ID: <552D0872.2070909@gmail.com> While experimenting with gcov and java tar coverage submissions I noticed the following oddities: - submitting gcov followed by java for the same build fails but it adds the java tar file to the buildfile cache nonetheless. Submitting just the java file in a new build afterwards copies the gcov coverage from the previous build (even though gcov coverage was not part of the new submission). - submitting java coverage with ctest_submit(CDASH_UPLOAD) creates rows in the coverage tables which a later ctest_submit() seems to remove again. I think the buildfile cache still points to that build though so that later submissions for the same coverage data try to copy non existing table rows. Removing the problematic entries from buildfile and submitting coverage data after everything else has been submitted seems to have fixed this somewhat. Nils From julien.jomier at kitware.com Mon Apr 20 05:24:15 2015 From: julien.jomier at kitware.com (Julien Jomier) Date: Mon, 20 Apr 2015 11:24:15 +0200 Subject: [Cdash] ANN: CMake Course - June 1 in Lyon, France In-Reply-To: <53BD4650.6070909@kitware.com> References: <53BD4650.6070909@kitware.com> Message-ID: <5534C5BF.2020605@kitware.com> Kitware will be holding a CMake training course on June 1, 2015 at Kitware's office in Lyon, France. This one-day course will cover CMake, CTest, CPack and CDash. Visit our website for more information and registration details (early registration and student discounts available): http://training.kitware.fr/browse/79 Note that the course will be taught in English. If you have any questions, please contact us at training at kitware.fr. We are looking forward to seeing you in Lyon, Julien -- Kitware SAS 26 rue Louis Gu?rin 69100 Villeurbanne, France http://www.kitware.eu From nilsgladitz at gmail.com Wed Apr 1 14:05:42 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 01 Apr 2015 16:05:42 +0200 Subject: [Cdash] Emma coverage In-Reply-To: References: <551A6F12.6030709@gmail.com> <551AE641.1090304@gmail.com> Message-ID: <551BFB36.60000@gmail.com> On 31.03.2015 20:41, Zack Galbreath wrote: > > https://gitlab.kitware.com/zackgalbreath/emma/commit/ac808cc7cdc90d1f6db8dcee96812e088fd17066 > Yes, it looks like it does apply on top of the emma release and the gwt patch that we were using: https://github.com/ngladitz/emma I can also verify that it generates the .json files. Thanks! I still have to look into how I'll run all this from the ctest client script rather than the project itself. Maybe it would make sense to mirror the package hierarchy for the .json output files to disambiguate in case there are multiple classes sharing the same name in different packages? Or is there already some other mechanism that I am overlooking? Nils From nilsgladitz at gmail.com Thu Apr 2 09:03:30 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 02 Apr 2015 11:03:30 +0200 Subject: [Cdash] Excluding sources from GcovTar coverage Message-ID: <551D05E2.8070305@gmail.com> I am looking into replacing ctest_coverage() with CMake's new CTestCoverageCollectGCOV module and CDash's new GcovTar coverage support. Is there an existing way to reproduce what ctest_coverage() did with CTEST_CUSTOM_COVERAGE_EXCLUDE? If there isn't, where would be the best place to implement something like it? e.g should CTestCoverageCollectGCOV exclude coverage files from the tar or should CDash ignore them? For the later case how would one inform CDash about the inclusion? An additional/existing json configuration file in the tar? Nils From nilsgladitz at gmail.com Thu Apr 2 15:04:47 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 02 Apr 2015 17:04:47 +0200 Subject: [Cdash] Excluding sources from GcovTar coverage In-Reply-To: <551D05E2.8070305@gmail.com> References: <551D05E2.8070305@gmail.com> Message-ID: <551D5A8F.1040604@gmail.com> On 04/02/2015 11:03 AM, Nils Gladitz wrote: > I am looking into replacing ctest_coverage() with CMake's new > CTestCoverageCollectGCOV module and CDash's new GcovTar coverage support. > > Is there an existing way to reproduce what ctest_coverage() did with > CTEST_CUSTOM_COVERAGE_EXCLUDE? This seems to work for me: https://github.com/ngladitz/cmake/commit/2cfcdd2b870025d776d0b5c246764f09594bdc34 Nils From bill.hoffman at kitware.com Thu Apr 2 16:51:19 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 02 Apr 2015 12:51:19 -0400 Subject: [Cdash] Excluding sources from GcovTar coverage In-Reply-To: <551D5A8F.1040604@gmail.com> References: <551D05E2.8070305@gmail.com> <551D5A8F.1040604@gmail.com> Message-ID: <551D7387.3050603@kitware.com> On 4/2/2015 11:04 AM, Nils Gladitz wrote: >> Is there an existing way to reproduce what ctest_coverage() did with >> CTEST_CUSTOM_COVERAGE_EXCLUDE? > > This seems to work for me: > https://github.com/ngladitz/cmake/commit/2cfcdd2b870025d776d0b5c246764f09594bdc34 > > > Nils That looks good to me. You should push it to CMake. I guess the test (CTestCoverageCollectGCOV) should be updated to include this somehow, but it was an oversight, and should be added. Thanks. -Bill From clinton at elemtech.com Fri Apr 3 04:13:35 2015 From: clinton at elemtech.com (clinton at elemtech.com) Date: Thu, 2 Apr 2015 22:13:35 -0600 (MDT) Subject: [Cdash] cdash backup directory not being cleaned up In-Reply-To: <5516F821.4080503@kitware.com> References: <1527052.O2EkId6Hhb@stryke> <5516F821.4080503@kitware.com> Message-ID: <907569729.9376271.1428034415680.JavaMail.zimbra@elemtech.com> I found out why this wasn't working for me. Its related to my apache setup putting cdash on a virtual host. In cdash/do_submit.php, I can fix this by changing the if(function_exists("curl_init") == TRUE) { $currentURI = get_server_URI(true); ... } to if(function_exists("curl_init") == TRUE) { $currentURI = get_server_URI(false); ... } Alternatively, I can change to $CDASH_CURL_REQUEST_LOCALHOST='0'; in the config. If the intent of the setting is to account for virtual hosts, its not obvious from the comments nor from the name of the variable. Nor is it obvious what the interaction is between these settings: $CDASH_CURL_REQUEST_LOCALHOST='0'; $CDASH_CURL_LOCALHOST_PREFIX=''; $CDASH_BASE_URL=''; I first tried setting CDASH_BASE_URL, but that had no effect. So anyway, for now I have $CDASH_CURL_REQUEST_LOCALHOST='0'; because I see several places where get_server_URI(true) is called. Clint ----- Original Message ----- > Dave, Clinton, > > I'm guessing the asynchronous call is not working properly. > Are you getting daily file changed at the top of the dashboard? > > Can you try to call the dailyupdates directly from your browser? > Something like: > > http://localhost/CDash/cdash/dailyupdatescurl.php?projectid=1 > > with the projectid being the id of your project. > > Let me know if that works (or not), > Julien > > On 27/03/2015 19:50, David Cole via Cdash wrote: > > Ah ha! I just checked mine, and I have 3.8 G worth of *.xml files > > dating all the way back to May 22, 2013 in my backup folder: the week > > that I set it up... > > > > I have this in my config.local.php, intending to keep things around for a > > week: > > $CDASH_BACKUP_TIMEFRAME = '168'; // in hours > > > > Good thing it's not a high-volume CDash server! > > > > Looking forward to a fix for this one. ;-) > > > > > > > > On Fri, Mar 27, 2015 at 1:19 PM, Clinton Stimpson > > wrote: > >> Hi, > >> > >> I have another problem with cdash. > >> > >> The backup directory contains the submitted .xml files. > >> I have in my cdash/config.php file > >> $CDASH_BACKUP_TIMEFRAME = '48'; // 48 hours > >> > >> According to this, the .xml files older than 48 hours are supposed to be > >> cleaned up when new submissions arrive. > >> http://www.vtk.org/Wiki/CDash:Administration#Backup_mechanism > >> > >> This is not the case for me. My backup directory is accumulating and > >> contains > >> files from the distant past. Much more than 48 hours ago. > >> > >> Is anyone else seeing this, or could it be specific to my setup? > >> For example, I install cdash in a version specific folder, and then make a > >> softlink for apache. I don't know if something like that would prevent > >> the > >> cleanup. Permissions shouldn't be a problem because apache can put the > >> files > >> there, so it should be able to remove them. > >> > >> Clint > >> _______________________________________________ > >> Cdash mailing list > >> Cdash at public.kitware.com > >> http://public.kitware.com/mailman/listinfo/cdash > > _______________________________________________ > > Cdash mailing list > > Cdash at public.kitware.com > > http://public.kitware.com/mailman/listinfo/cdash > > > From nilsgladitz at gmail.com Fri Apr 3 10:14:49 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 03 Apr 2015 12:14:49 +0200 Subject: [Cdash] Excluding sources from GcovTar coverage In-Reply-To: <551D7387.3050603@kitware.com> References: <551D05E2.8070305@gmail.com> <551D5A8F.1040604@gmail.com> <551D7387.3050603@kitware.com> Message-ID: <551E6819.8050308@gmail.com> On 02.04.2015 18:51, Bill Hoffman wrote: > On 4/2/2015 11:04 AM, Nils Gladitz wrote: >> >> This seems to work for me: >> https://github.com/ngladitz/cmake/commit/2cfcdd2b870025d776d0b5c246764f09594bdc34 >> >> >> >> Nils > That looks good to me. You should push it to CMake. I guess the > test (CTestCoverageCollectGCOV) should be updated to include this > somehow, but it was an oversight, and should be added. > Thanks! I incorporated your break() suggestion, extended the test case and merged to next for testing. Nils From zack.galbreath at kitware.com Fri Apr 10 15:32:36 2015 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Fri, 10 Apr 2015 11:32:36 -0400 Subject: [Cdash] Emma coverage In-Reply-To: <551BFB36.60000@gmail.com> References: <551A6F12.6030709@gmail.com> <551AE641.1090304@gmail.com> <551BFB36.60000@gmail.com> Message-ID: On Wed, Apr 1, 2015 at 10:05 AM, Nils Gladitz wrote: > I still have to look into how I'll run all this from the ctest client > script rather than the project itself. > Locally I'm doing something very similar to CTestCoverageCollectGCOV, but this hasn't made it into CMake/Modules yet. > Maybe it would make sense to mirror the package hierarchy for the .json > output files to disambiguate in case there are multiple classes sharing the > same name in different packages? > Or is there already some other mechanism that I am overlooking? > The .json files should contain the package of the class. This is what CDash uses to report the coverage, as opposed to the per-directory view that it uses for gcov. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Apr 10 15:37:47 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 10 Apr 2015 17:37:47 +0200 Subject: [Cdash] Emma coverage In-Reply-To: References: <551A6F12.6030709@gmail.com> <551AE641.1090304@gmail.com> <551BFB36.60000@gmail.com> Message-ID: <5527EE4B.7090207@gmail.com> On 10.04.2015 17:32, Zack Galbreath wrote: > > On Wed, Apr 1, 2015 at 10:05 AM, Nils Gladitz > wrote: > > I still have to look into how I'll run all this from the ctest > client script rather than the project itself. > > > Locally I'm doing something very similar to CTestCoverageCollectGCOV, > but this hasn't made it into CMake/Modules yet. > Yes that is what I got too now. > Maybe it would make sense to mirror the package hierarchy for the > .json output files to disambiguate in case there are multiple > classes sharing the same name in different packages? > Or is there already some other mechanism that I am overlooking? > > > The .json files should contain the package of the class. This is what > CDash uses to report the coverage, as opposed to the per-directory > view that it uses for gcov. Doesn't that break though if there are two classes with the same name in two distinct packages? Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From zack.galbreath at kitware.com Fri Apr 10 15:55:46 2015 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Fri, 10 Apr 2015 11:55:46 -0400 Subject: [Cdash] Emma coverage In-Reply-To: <5527EE4B.7090207@gmail.com> References: <551A6F12.6030709@gmail.com> <551AE641.1090304@gmail.com> <551BFB36.60000@gmail.com> <5527EE4B.7090207@gmail.com> Message-ID: On Fri, Apr 10, 2015 at 11:37 AM, Nils Gladitz wrote: > The .json files should contain the package of the class. This is what > CDash uses to report the coverage, as opposed to the per-directory view > that it uses for gcov. > > > Doesn't that break though if there are two classes with the same name in > two distinct packages? After looking more closely I think you're right. We should probably incorporate the package name into $path for each file: https://github.com/Kitware/CDash/blob/master/xml_handlers/JavaJSONTar_handler.php#L164-L167 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Apr 10 16:02:31 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 10 Apr 2015 18:02:31 +0200 Subject: [Cdash] Emma coverage In-Reply-To: References: <551A6F12.6030709@gmail.com> <551AE641.1090304@gmail.com> <551BFB36.60000@gmail.com> <5527EE4B.7090207@gmail.com> Message-ID: <5527F417.5050809@gmail.com> On 10.04.2015 17:55, Zack Galbreath wrote: > On Fri, Apr 10, 2015 at 11:37 AM, Nils Gladitz > wrote: > >> The .json files should contain the package of the class. This is >> what CDash uses to report the coverage, as opposed to the >> per-directory view that it uses for gcov. > > Doesn't that break though if there are two classes with the same > name in two distinct packages? > > > > After looking more closely I think you're right. We should probably > incorporate the package name into $path for each file: > > https://github.com/Kitware/CDash/blob/master/xml_handlers/JavaJSONTar_handler.php#L164-L167 I mean wouldn't emma currently try to generate the same .json file for both classes? Since even though they are in different packages they would currently have the same .java.json filename written into the same output directory. Hence one overwriting the other and the former being lost? Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From zack.galbreath at kitware.com Fri Apr 10 16:43:47 2015 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Fri, 10 Apr 2015 12:43:47 -0400 Subject: [Cdash] Emma coverage In-Reply-To: <5527F417.5050809@gmail.com> References: <551A6F12.6030709@gmail.com> <551AE641.1090304@gmail.com> <551BFB36.60000@gmail.com> <5527EE4B.7090207@gmail.com> <5527F417.5050809@gmail.com> Message-ID: On Fri, Apr 10, 2015 at 12:02 PM, Nils Gladitz wrote: > I mean wouldn't emma currently try to generate the same .json file for > both classes? > Since even though they are in different packages they would currently have > the same .java.json filename written into the same output directory. > > Hence one overwriting the other and the former being lost? > That makes sense too. I guess we'll have to do something a bit more careful on the Java side. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Apr 10 18:08:54 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 10 Apr 2015 20:08:54 +0200 Subject: [Cdash] Emma coverage In-Reply-To: References: <551A6F12.6030709@gmail.com> <551AE641.1090304@gmail.com> <551BFB36.60000@gmail.com> <5527EE4B.7090207@gmail.com> <5527F417.5050809@gmail.com> Message-ID: <552811B6.4010106@gmail.com> On 10.04.2015 18:43, Zack Galbreath wrote: > On Fri, Apr 10, 2015 at 12:02 PM, Nils Gladitz > wrote: > > I mean wouldn't emma currently try to generate the same .json file > for both classes? > Since even though they are in different packages they would > currently have the same .java.json filename written into > the same output directory. > > Hence one overwriting the other and the former being lost? > > > > That makes sense too. I guess we'll have to do something a bit more > careful on the Java side. Does this look sensible? https://github.com/ngladitz/emma/commit/cba7bad1be36d5e135f2bd02f498d35943562801 I hope it isn't too obvious that I don't do much java :) Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Mon Apr 13 08:29:30 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 13 Apr 2015 10:29:30 +0200 Subject: [Cdash] Allow multiple coverage submissions for the same buildid Message-ID: <552B7E6A.9040300@gmail.com> I am trying to submit both gcov and java emma coverage from the same build which I think leads to: SQL error: ERROR: duplicate key value violates unique constraint "coveragesummary_pkey" Would it be possible to add a column to the coveragesummary table for the coverage type (e.g. gcov, emma) and make it part of the primary key so that multiple coverage submissions of different type become valid? Would any other changes be required to make this work? Nils From DLRdave at aol.com Mon Apr 13 10:35:05 2015 From: DLRdave at aol.com (David Cole) Date: Mon, 13 Apr 2015 06:35:05 -0400 Subject: [Cdash] Allow multiple coverage submissions for the same buildid In-Reply-To: <552B7E6A.9040300@gmail.com> References: <552B7E6A.9040300@gmail.com> Message-ID: Why not simply submit another build with the second coverage type (and a different build name)? I think you'll also need to decide how to handle multiple coverage types from the link on top level page, and on the coverage summary page itself. (Either links to multiple summaries, or a summary that takes into account multiple types.) Certainly more work than simply adding to the primary key... On Mon, Apr 13, 2015 at 4:29 AM, Nils Gladitz wrote: > I am trying to submit both gcov and java emma coverage from the same build > which I think leads to: > > SQL error: ERROR: duplicate key value violates unique constraint > "coveragesummary_pkey" > > Would it be possible to add a column to the coveragesummary table for the > coverage type (e.g. gcov, emma) and make it part of the primary key so that > multiple coverage submissions of different type become valid? > > Would any other changes be required to make this work? > > Nils > _______________________________________________ > Cdash mailing list > Cdash at public.kitware.com > http://public.kitware.com/mailman/listinfo/cdash From nilsgladitz at gmail.com Mon Apr 13 10:47:33 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 13 Apr 2015 12:47:33 +0200 Subject: [Cdash] Allow multiple coverage submissions for the same buildid In-Reply-To: References: <552B7E6A.9040300@gmail.com> Message-ID: <552B9EC5.5030700@gmail.com> On 04/13/2015 12:35 PM, David Cole wrote: > Why not simply submit another build with the second coverage type (and > a different build name)? That sounds good too. How would I go about implementing this? Can this be done from a single ctest job script run or would I have to run it once for each buildid? I assume it would involve more than e.g.: set(CTEST_BUILD_NAME "${CTEST_BUILD_NAME}-emma") ctest_submit(CDASH_UPLOAD ... CDASH_UPLOAD_TYPE JavaJSONTar) ? > I think you'll also need to decide how to handle multiple coverage > types from the link on top level page, and on the coverage summary > page itself. (Either links to multiple summaries, or a summary that > takes into account multiple types.) > > Certainly more work than simply adding to the primary key... I was thinking separate summaries like I would get from distinct builds. If I can submit just the emma coverage under a new buildid that would basically be what I want. Nils From nilsgladitz at gmail.com Tue Apr 14 12:30:42 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 14 Apr 2015 14:30:42 +0200 Subject: [Cdash] buildfile cache and json tar issues Message-ID: <552D0872.2070909@gmail.com> While experimenting with gcov and java tar coverage submissions I noticed the following oddities: - submitting gcov followed by java for the same build fails but it adds the java tar file to the buildfile cache nonetheless. Submitting just the java file in a new build afterwards copies the gcov coverage from the previous build (even though gcov coverage was not part of the new submission). - submitting java coverage with ctest_submit(CDASH_UPLOAD) creates rows in the coverage tables which a later ctest_submit() seems to remove again. I think the buildfile cache still points to that build though so that later submissions for the same coverage data try to copy non existing table rows. Removing the problematic entries from buildfile and submitting coverage data after everything else has been submitted seems to have fixed this somewhat. Nils From julien.jomier at kitware.com Mon Apr 20 09:24:15 2015 From: julien.jomier at kitware.com (Julien Jomier) Date: Mon, 20 Apr 2015 11:24:15 +0200 Subject: [Cdash] ANN: CMake Course - June 1 in Lyon, France In-Reply-To: <53BD4650.6070909@kitware.com> References: <53BD4650.6070909@kitware.com> Message-ID: <5534C5BF.2020605@kitware.com> Kitware will be holding a CMake training course on June 1, 2015 at Kitware's office in Lyon, France. This one-day course will cover CMake, CTest, CPack and CDash. Visit our website for more information and registration details (early registration and student discounts available): http://training.kitware.fr/browse/79 Note that the course will be taught in English. If you have any questions, please contact us at training at kitware.fr. We are looking forward to seeing you in Lyon, Julien -- Kitware SAS 26 rue Louis Gu?rin 69100 Villeurbanne, France http://www.kitware.eu From nilsgladitz at gmail.com Wed Apr 1 14:05:42 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 01 Apr 2015 16:05:42 +0200 Subject: [Cdash] Emma coverage In-Reply-To: References: <551A6F12.6030709@gmail.com> <551AE641.1090304@gmail.com> Message-ID: <551BFB36.60000@gmail.com> On 31.03.2015 20:41, Zack Galbreath wrote: > > https://gitlab.kitware.com/zackgalbreath/emma/commit/ac808cc7cdc90d1f6db8dcee96812e088fd17066 > Yes, it looks like it does apply on top of the emma release and the gwt patch that we were using: https://github.com/ngladitz/emma I can also verify that it generates the .json files. Thanks! I still have to look into how I'll run all this from the ctest client script rather than the project itself. Maybe it would make sense to mirror the package hierarchy for the .json output files to disambiguate in case there are multiple classes sharing the same name in different packages? Or is there already some other mechanism that I am overlooking? Nils From nilsgladitz at gmail.com Thu Apr 2 09:03:30 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 02 Apr 2015 11:03:30 +0200 Subject: [Cdash] Excluding sources from GcovTar coverage Message-ID: <551D05E2.8070305@gmail.com> I am looking into replacing ctest_coverage() with CMake's new CTestCoverageCollectGCOV module and CDash's new GcovTar coverage support. Is there an existing way to reproduce what ctest_coverage() did with CTEST_CUSTOM_COVERAGE_EXCLUDE? If there isn't, where would be the best place to implement something like it? e.g should CTestCoverageCollectGCOV exclude coverage files from the tar or should CDash ignore them? For the later case how would one inform CDash about the inclusion? An additional/existing json configuration file in the tar? Nils From nilsgladitz at gmail.com Thu Apr 2 15:04:47 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 02 Apr 2015 17:04:47 +0200 Subject: [Cdash] Excluding sources from GcovTar coverage In-Reply-To: <551D05E2.8070305@gmail.com> References: <551D05E2.8070305@gmail.com> Message-ID: <551D5A8F.1040604@gmail.com> On 04/02/2015 11:03 AM, Nils Gladitz wrote: > I am looking into replacing ctest_coverage() with CMake's new > CTestCoverageCollectGCOV module and CDash's new GcovTar coverage support. > > Is there an existing way to reproduce what ctest_coverage() did with > CTEST_CUSTOM_COVERAGE_EXCLUDE? This seems to work for me: https://github.com/ngladitz/cmake/commit/2cfcdd2b870025d776d0b5c246764f09594bdc34 Nils From bill.hoffman at kitware.com Thu Apr 2 16:51:19 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 02 Apr 2015 12:51:19 -0400 Subject: [Cdash] Excluding sources from GcovTar coverage In-Reply-To: <551D5A8F.1040604@gmail.com> References: <551D05E2.8070305@gmail.com> <551D5A8F.1040604@gmail.com> Message-ID: <551D7387.3050603@kitware.com> On 4/2/2015 11:04 AM, Nils Gladitz wrote: >> Is there an existing way to reproduce what ctest_coverage() did with >> CTEST_CUSTOM_COVERAGE_EXCLUDE? > > This seems to work for me: > https://github.com/ngladitz/cmake/commit/2cfcdd2b870025d776d0b5c246764f09594bdc34 > > > Nils That looks good to me. You should push it to CMake. I guess the test (CTestCoverageCollectGCOV) should be updated to include this somehow, but it was an oversight, and should be added. Thanks. -Bill From clinton at elemtech.com Fri Apr 3 04:13:35 2015 From: clinton at elemtech.com (clinton at elemtech.com) Date: Thu, 2 Apr 2015 22:13:35 -0600 (MDT) Subject: [Cdash] cdash backup directory not being cleaned up In-Reply-To: <5516F821.4080503@kitware.com> References: <1527052.O2EkId6Hhb@stryke> <5516F821.4080503@kitware.com> Message-ID: <907569729.9376271.1428034415680.JavaMail.zimbra@elemtech.com> I found out why this wasn't working for me. Its related to my apache setup putting cdash on a virtual host. In cdash/do_submit.php, I can fix this by changing the if(function_exists("curl_init") == TRUE) { $currentURI = get_server_URI(true); ... } to if(function_exists("curl_init") == TRUE) { $currentURI = get_server_URI(false); ... } Alternatively, I can change to $CDASH_CURL_REQUEST_LOCALHOST='0'; in the config. If the intent of the setting is to account for virtual hosts, its not obvious from the comments nor from the name of the variable. Nor is it obvious what the interaction is between these settings: $CDASH_CURL_REQUEST_LOCALHOST='0'; $CDASH_CURL_LOCALHOST_PREFIX=''; $CDASH_BASE_URL=''; I first tried setting CDASH_BASE_URL, but that had no effect. So anyway, for now I have $CDASH_CURL_REQUEST_LOCALHOST='0'; because I see several places where get_server_URI(true) is called. Clint ----- Original Message ----- > Dave, Clinton, > > I'm guessing the asynchronous call is not working properly. > Are you getting daily file changed at the top of the dashboard? > > Can you try to call the dailyupdates directly from your browser? > Something like: > > http://localhost/CDash/cdash/dailyupdatescurl.php?projectid=1 > > with the projectid being the id of your project. > > Let me know if that works (or not), > Julien > > On 27/03/2015 19:50, David Cole via Cdash wrote: > > Ah ha! I just checked mine, and I have 3.8 G worth of *.xml files > > dating all the way back to May 22, 2013 in my backup folder: the week > > that I set it up... > > > > I have this in my config.local.php, intending to keep things around for a > > week: > > $CDASH_BACKUP_TIMEFRAME = '168'; // in hours > > > > Good thing it's not a high-volume CDash server! > > > > Looking forward to a fix for this one. ;-) > > > > > > > > On Fri, Mar 27, 2015 at 1:19 PM, Clinton Stimpson > > wrote: > >> Hi, > >> > >> I have another problem with cdash. > >> > >> The backup directory contains the submitted .xml files. > >> I have in my cdash/config.php file > >> $CDASH_BACKUP_TIMEFRAME = '48'; // 48 hours > >> > >> According to this, the .xml files older than 48 hours are supposed to be > >> cleaned up when new submissions arrive. > >> http://www.vtk.org/Wiki/CDash:Administration#Backup_mechanism > >> > >> This is not the case for me. My backup directory is accumulating and > >> contains > >> files from the distant past. Much more than 48 hours ago. > >> > >> Is anyone else seeing this, or could it be specific to my setup? > >> For example, I install cdash in a version specific folder, and then make a > >> softlink for apache. I don't know if something like that would prevent > >> the > >> cleanup. Permissions shouldn't be a problem because apache can put the > >> files > >> there, so it should be able to remove them. > >> > >> Clint > >> _______________________________________________ > >> Cdash mailing list > >> Cdash at public.kitware.com > >> http://public.kitware.com/mailman/listinfo/cdash > > _______________________________________________ > > Cdash mailing list > > Cdash at public.kitware.com > > http://public.kitware.com/mailman/listinfo/cdash > > > From nilsgladitz at gmail.com Fri Apr 3 10:14:49 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 03 Apr 2015 12:14:49 +0200 Subject: [Cdash] Excluding sources from GcovTar coverage In-Reply-To: <551D7387.3050603@kitware.com> References: <551D05E2.8070305@gmail.com> <551D5A8F.1040604@gmail.com> <551D7387.3050603@kitware.com> Message-ID: <551E6819.8050308@gmail.com> On 02.04.2015 18:51, Bill Hoffman wrote: > On 4/2/2015 11:04 AM, Nils Gladitz wrote: >> >> This seems to work for me: >> https://github.com/ngladitz/cmake/commit/2cfcdd2b870025d776d0b5c246764f09594bdc34 >> >> >> >> Nils > That looks good to me. You should push it to CMake. I guess the > test (CTestCoverageCollectGCOV) should be updated to include this > somehow, but it was an oversight, and should be added. > Thanks! I incorporated your break() suggestion, extended the test case and merged to next for testing. Nils From zack.galbreath at kitware.com Fri Apr 10 15:32:36 2015 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Fri, 10 Apr 2015 11:32:36 -0400 Subject: [Cdash] Emma coverage In-Reply-To: <551BFB36.60000@gmail.com> References: <551A6F12.6030709@gmail.com> <551AE641.1090304@gmail.com> <551BFB36.60000@gmail.com> Message-ID: On Wed, Apr 1, 2015 at 10:05 AM, Nils Gladitz wrote: > I still have to look into how I'll run all this from the ctest client > script rather than the project itself. > Locally I'm doing something very similar to CTestCoverageCollectGCOV, but this hasn't made it into CMake/Modules yet. > Maybe it would make sense to mirror the package hierarchy for the .json > output files to disambiguate in case there are multiple classes sharing the > same name in different packages? > Or is there already some other mechanism that I am overlooking? > The .json files should contain the package of the class. This is what CDash uses to report the coverage, as opposed to the per-directory view that it uses for gcov. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Apr 10 15:37:47 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 10 Apr 2015 17:37:47 +0200 Subject: [Cdash] Emma coverage In-Reply-To: References: <551A6F12.6030709@gmail.com> <551AE641.1090304@gmail.com> <551BFB36.60000@gmail.com> Message-ID: <5527EE4B.7090207@gmail.com> On 10.04.2015 17:32, Zack Galbreath wrote: > > On Wed, Apr 1, 2015 at 10:05 AM, Nils Gladitz > wrote: > > I still have to look into how I'll run all this from the ctest > client script rather than the project itself. > > > Locally I'm doing something very similar to CTestCoverageCollectGCOV, > but this hasn't made it into CMake/Modules yet. > Yes that is what I got too now. > Maybe it would make sense to mirror the package hierarchy for the > .json output files to disambiguate in case there are multiple > classes sharing the same name in different packages? > Or is there already some other mechanism that I am overlooking? > > > The .json files should contain the package of the class. This is what > CDash uses to report the coverage, as opposed to the per-directory > view that it uses for gcov. Doesn't that break though if there are two classes with the same name in two distinct packages? Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From zack.galbreath at kitware.com Fri Apr 10 15:55:46 2015 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Fri, 10 Apr 2015 11:55:46 -0400 Subject: [Cdash] Emma coverage In-Reply-To: <5527EE4B.7090207@gmail.com> References: <551A6F12.6030709@gmail.com> <551AE641.1090304@gmail.com> <551BFB36.60000@gmail.com> <5527EE4B.7090207@gmail.com> Message-ID: On Fri, Apr 10, 2015 at 11:37 AM, Nils Gladitz wrote: > The .json files should contain the package of the class. This is what > CDash uses to report the coverage, as opposed to the per-directory view > that it uses for gcov. > > > Doesn't that break though if there are two classes with the same name in > two distinct packages? After looking more closely I think you're right. We should probably incorporate the package name into $path for each file: https://github.com/Kitware/CDash/blob/master/xml_handlers/JavaJSONTar_handler.php#L164-L167 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Apr 10 16:02:31 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 10 Apr 2015 18:02:31 +0200 Subject: [Cdash] Emma coverage In-Reply-To: References: <551A6F12.6030709@gmail.com> <551AE641.1090304@gmail.com> <551BFB36.60000@gmail.com> <5527EE4B.7090207@gmail.com> Message-ID: <5527F417.5050809@gmail.com> On 10.04.2015 17:55, Zack Galbreath wrote: > On Fri, Apr 10, 2015 at 11:37 AM, Nils Gladitz > wrote: > >> The .json files should contain the package of the class. This is >> what CDash uses to report the coverage, as opposed to the >> per-directory view that it uses for gcov. > > Doesn't that break though if there are two classes with the same > name in two distinct packages? > > > > After looking more closely I think you're right. We should probably > incorporate the package name into $path for each file: > > https://github.com/Kitware/CDash/blob/master/xml_handlers/JavaJSONTar_handler.php#L164-L167 I mean wouldn't emma currently try to generate the same .json file for both classes? Since even though they are in different packages they would currently have the same .java.json filename written into the same output directory. Hence one overwriting the other and the former being lost? Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From zack.galbreath at kitware.com Fri Apr 10 16:43:47 2015 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Fri, 10 Apr 2015 12:43:47 -0400 Subject: [Cdash] Emma coverage In-Reply-To: <5527F417.5050809@gmail.com> References: <551A6F12.6030709@gmail.com> <551AE641.1090304@gmail.com> <551BFB36.60000@gmail.com> <5527EE4B.7090207@gmail.com> <5527F417.5050809@gmail.com> Message-ID: On Fri, Apr 10, 2015 at 12:02 PM, Nils Gladitz wrote: > I mean wouldn't emma currently try to generate the same .json file for > both classes? > Since even though they are in different packages they would currently have > the same .java.json filename written into the same output directory. > > Hence one overwriting the other and the former being lost? > That makes sense too. I guess we'll have to do something a bit more careful on the Java side. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Apr 10 18:08:54 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 10 Apr 2015 20:08:54 +0200 Subject: [Cdash] Emma coverage In-Reply-To: References: <551A6F12.6030709@gmail.com> <551AE641.1090304@gmail.com> <551BFB36.60000@gmail.com> <5527EE4B.7090207@gmail.com> <5527F417.5050809@gmail.com> Message-ID: <552811B6.4010106@gmail.com> On 10.04.2015 18:43, Zack Galbreath wrote: > On Fri, Apr 10, 2015 at 12:02 PM, Nils Gladitz > wrote: > > I mean wouldn't emma currently try to generate the same .json file > for both classes? > Since even though they are in different packages they would > currently have the same .java.json filename written into > the same output directory. > > Hence one overwriting the other and the former being lost? > > > > That makes sense too. I guess we'll have to do something a bit more > careful on the Java side. Does this look sensible? https://github.com/ngladitz/emma/commit/cba7bad1be36d5e135f2bd02f498d35943562801 I hope it isn't too obvious that I don't do much java :) Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Mon Apr 13 08:29:30 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 13 Apr 2015 10:29:30 +0200 Subject: [Cdash] Allow multiple coverage submissions for the same buildid Message-ID: <552B7E6A.9040300@gmail.com> I am trying to submit both gcov and java emma coverage from the same build which I think leads to: SQL error: ERROR: duplicate key value violates unique constraint "coveragesummary_pkey" Would it be possible to add a column to the coveragesummary table for the coverage type (e.g. gcov, emma) and make it part of the primary key so that multiple coverage submissions of different type become valid? Would any other changes be required to make this work? Nils From DLRdave at aol.com Mon Apr 13 10:35:05 2015 From: DLRdave at aol.com (David Cole) Date: Mon, 13 Apr 2015 06:35:05 -0400 Subject: [Cdash] Allow multiple coverage submissions for the same buildid In-Reply-To: <552B7E6A.9040300@gmail.com> References: <552B7E6A.9040300@gmail.com> Message-ID: Why not simply submit another build with the second coverage type (and a different build name)? I think you'll also need to decide how to handle multiple coverage types from the link on top level page, and on the coverage summary page itself. (Either links to multiple summaries, or a summary that takes into account multiple types.) Certainly more work than simply adding to the primary key... On Mon, Apr 13, 2015 at 4:29 AM, Nils Gladitz wrote: > I am trying to submit both gcov and java emma coverage from the same build > which I think leads to: > > SQL error: ERROR: duplicate key value violates unique constraint > "coveragesummary_pkey" > > Would it be possible to add a column to the coveragesummary table for the > coverage type (e.g. gcov, emma) and make it part of the primary key so that > multiple coverage submissions of different type become valid? > > Would any other changes be required to make this work? > > Nils > _______________________________________________ > Cdash mailing list > Cdash at public.kitware.com > http://public.kitware.com/mailman/listinfo/cdash From nilsgladitz at gmail.com Mon Apr 13 10:47:33 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 13 Apr 2015 12:47:33 +0200 Subject: [Cdash] Allow multiple coverage submissions for the same buildid In-Reply-To: References: <552B7E6A.9040300@gmail.com> Message-ID: <552B9EC5.5030700@gmail.com> On 04/13/2015 12:35 PM, David Cole wrote: > Why not simply submit another build with the second coverage type (and > a different build name)? That sounds good too. How would I go about implementing this? Can this be done from a single ctest job script run or would I have to run it once for each buildid? I assume it would involve more than e.g.: set(CTEST_BUILD_NAME "${CTEST_BUILD_NAME}-emma") ctest_submit(CDASH_UPLOAD ... CDASH_UPLOAD_TYPE JavaJSONTar) ? > I think you'll also need to decide how to handle multiple coverage > types from the link on top level page, and on the coverage summary > page itself. (Either links to multiple summaries, or a summary that > takes into account multiple types.) > > Certainly more work than simply adding to the primary key... I was thinking separate summaries like I would get from distinct builds. If I can submit just the emma coverage under a new buildid that would basically be what I want. Nils From nilsgladitz at gmail.com Tue Apr 14 12:30:42 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 14 Apr 2015 14:30:42 +0200 Subject: [Cdash] buildfile cache and json tar issues Message-ID: <552D0872.2070909@gmail.com> While experimenting with gcov and java tar coverage submissions I noticed the following oddities: - submitting gcov followed by java for the same build fails but it adds the java tar file to the buildfile cache nonetheless. Submitting just the java file in a new build afterwards copies the gcov coverage from the previous build (even though gcov coverage was not part of the new submission). - submitting java coverage with ctest_submit(CDASH_UPLOAD) creates rows in the coverage tables which a later ctest_submit() seems to remove again. I think the buildfile cache still points to that build though so that later submissions for the same coverage data try to copy non existing table rows. Removing the problematic entries from buildfile and submitting coverage data after everything else has been submitted seems to have fixed this somewhat. Nils From julien.jomier at kitware.com Mon Apr 20 09:24:15 2015 From: julien.jomier at kitware.com (Julien Jomier) Date: Mon, 20 Apr 2015 11:24:15 +0200 Subject: [Cdash] ANN: CMake Course - June 1 in Lyon, France In-Reply-To: <53BD4650.6070909@kitware.com> References: <53BD4650.6070909@kitware.com> Message-ID: <5534C5BF.2020605@kitware.com> Kitware will be holding a CMake training course on June 1, 2015 at Kitware's office in Lyon, France. This one-day course will cover CMake, CTest, CPack and CDash. Visit our website for more information and registration details (early registration and student discounts available): http://training.kitware.fr/browse/79 Note that the course will be taught in English. If you have any questions, please contact us at training at kitware.fr. We are looking forward to seeing you in Lyon, Julien -- Kitware SAS 26 rue Louis Gu?rin 69100 Villeurbanne, France http://www.kitware.eu