From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31138 invoked by alias); 8 Oct 2007 16:25:09 -0000 Received: (qmail 31121 invoked by uid 22791); 8 Oct 2007 16:25:08 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 08 Oct 2007 16:25:00 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id E09142AC0C2; Mon, 8 Oct 2007 12:24:58 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1LXeueabSZgn; Mon, 8 Oct 2007 12:24:58 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id A0F8E2AC0BA; Mon, 8 Oct 2007 12:24:58 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 72496E7B58; Mon, 8 Oct 2007 09:24:56 -0700 (PDT) Date: Mon, 08 Oct 2007 16:25:00 -0000 From: Joel Brobecker To: Pierre Muller , gdb-patches@sourceware.org Subject: Re: [RFA] ARI fix: Remove asprintf in breakpoint.c Message-ID: <20071008162456.GP3570@adacore.com> References: <009c01c809a5$c05be1c0$4113a540$@u-strasbg.fr> <20071008134219.GK3570@adacore.com> <00a001c809b2$56fc8ec0$04f5ac40$@u-strasbg.fr> <20071008150155.GM3570@adacore.com> <000501c809bf$49bd85e0$dd3891a0$@u-strasbg.fr> <20071008160904.GA19094@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071008160904.GA19094@caradoc.them.org> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-10/txt/msg00169.txt.bz2 > > Concerning the overnight running of testsuites > > with different patches, does anyone have some > > script that automates this? > > No - but it's reasonable to test them together in a single test run, > I think. That's indeed what I meant. However, I can see the need for a script if you have to do two runs (one before patching, and one after). I have a set of scripts that I can send, but they are deeply dependent on my entire environment (including the interactive shell sessions). My scripts are pretty complex because I re-use them in many different contexts on 3 different sites (in Paris, in New York, and at my home). Unless someone else can share a script, I think it'll be simpler for you to write a script of your own. The essence of my script is: - Take patch name from argument lists. Verify that patch exists before continuing. Nothing worse than having a failure 12hours later because you mistyped your patch name :) - mkdir test-dir - cd test-dir - cp -R gdb-sources . - cd gdb-sources - configure - make - cd gdb/testsuite - make check - cp gdb.sum gdb.sum.ref - cp gdb.log gdb.log.ref - cd .. - patch -p0 < your-patch - make - cd testsuite - make check (with various checks against $? at the end of steps such as the GDB build, so that you don't continue if something failed). As I said, if the stream of your patches is relatively small, I don't mind doing the testing for you, since it's pretty automated on my side. But if you are going to contribute a regular amount of patches, it makes sense to invest the time in them. -- Joel