From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16440 invoked by alias); 28 Jun 2013 09:05:58 -0000 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 Received: (qmail 16428 invoked by uid 89); 28 Jun 2013 09:05:57 -0000 X-Spam-SWARE-Status: No, score=-8.1 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 28 Jun 2013 09:05:57 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r5S95swL026211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Jun 2013 05:05:54 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r5S95qii017409; Fri, 28 Jun 2013 05:05:53 -0400 Message-ID: <51CD51F0.1080203@redhat.com> Date: Fri, 28 Jun 2013 09:55:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [PATCH 1/9] Reimport gnulib from scratch. References: <20130627185200.6625.10526.stgit@brno.lan> <20130627185207.6625.27448.stgit@brno.lan> <51CD4C4A.9030605@codesourcery.com> In-Reply-To: <51CD4C4A.9030605@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-06/txt/msg00870.txt.bz2 On 06/28/2013 09:41 AM, Yao Qi wrote: > On 06/28/2013 02:52 AM, Pedro Alves wrote: >> I tried moving aside gnulib/import/, and re-running the our >> gnulib/update-gnulib.sh script, and surprisingly, I get a different >> result compared to what's in the tree. This is with pristine FSF >> autoconf and FSF automake, at the versions required by >> update-gnulib.sh. However, if I just run the update-gnulib.sh scripts >> against the_existing_ tree, then nothing changes... I suspect >> gnulib-tool's merge logic might be preserving some things by design. >> I think we should put this in regardless, as a "get rid of cruft that >> might have accumulated over gnulib updates". onceonly.m4 seems to fit >> in that category. > > Pedro, > I tried to run update-gnulib.sh to import module unistd, and the result > looks right to me. Don't know why we need to reimport gnulib here. You misunderstand. I never said we _need_ to reimport gnulib in order to pull in unistd. This patch is in the series as I based subsequent patches on top of it. It isn't strictly necessary, and we could do this reimporting after the series instead. Sorry if that wasn't clear. > Here are my steps, > > 1. cd to and check out commit. > 8d5bd1402003bd0153984b138735adf537d960b0, which is required by > update-gnulib.sh > > 2. Modify update-gnulib.sh to add unistd into IMPORTED_GNULIB_MODULES, > > 3. Run 'bash update-gnulib.sh '. > > Here is the diff of aclocal.m4, for the reference sake. As you see from your diff, doing things that way preserves onlyonce.m4. Now try what I suggested. Do: 1.1. mv import import.old 1.2. mkdir import 1.3. Run 'bash update-gnulib.sh '. 1.4. Diff the resulting gnulib/ trees. (or git diff, or whatever) You'll (I hope) differences similar this patch #1. At this point, one begins to wonder whether unistd is related. Then go back to a pristine tree, and do the same exercise, but without importing unistd: 2.1. Run 'bash update-gnulib.sh '. 2.2. Diff the result, nothing should have changed. 2.2. mv import import.old 2.3. mkdir import 2.4. Run 'bash update-gnulib.sh '. 2.5. Diff the resulting gnulib/ trees. At 2.5, you should see a diff just like this patch #1. What I'm saying is that we should be able to generate our gnulib import from scratch and end up with the exact same as we have in the tree. But, if we actually try doing it, we don't! So this patch proposes getting rid of the cruft gnulib-tool is leaving behind, and I'm suggesting we should probably be doing this always. I'd be interested in knowing if you can reproduce these results. -- Pedro Alves