From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90956 invoked by alias); 16 Jun 2018 03:05:37 -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 90938 invoked by uid 89); 16 Jun 2018 03:05:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,KAM_NUMSUBJECT,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 spammy=bumps X-Spam-User: qpsmtpd, 2 recipients X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 16 Jun 2018 03:05:34 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id w5G35NVR010669 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 15 Jun 2018 23:05:28 -0400 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 34ED01E02D; Fri, 15 Jun 2018 23:05:23 -0400 (EDT) From: Simon Marchi Subject: Re: [PATCH 1/2] Bump to autoconf 2.69 and automake 1.15.1 To: Joseph Myers Cc: gdb-patches@sourceware.org, binutils@sourceware.org, Simon Marchi References: <20180615004309.29913-1-simon.marchi@polymtl.ca> Message-ID: Date: Sat, 16 Jun 2018 03:05:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Sat, 16 Jun 2018 03:05:23 +0000 X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00416.txt.bz2 On 2018-06-15 01:29 PM, Joseph Myers wrote: > Questions: > > * Are all the shared files and directories fully in sync between the GCC > and binutils-gdb trees before this patch? Shared directories include > config, intl, parts of include, libdecnumber, libiberty, zlib, for > example. - config: binutils-gdb is behind, needs syncing - include: I'll need more precise guidance on how to sync - intl: in sync - libdecnumber: binutils-gdb is behind, needs syncing. Except one patchlet that binutils-gdb has and gcc doesn't have which adds a TAGS target to the Makefile. Could one of you see if you could import that change to gcc? - libiberty: binutils-gdb is behind, needs syncing - zlib: binutils-gdb is behind, needs syncing I'm sending a series that syncs config, libdecnumber, libiberty and zlib in a moment. > * Where you are changing shared files and directories, do any changes to > *non-generated* files other than config/override.m4 depend on the autoconf > / automake updates, or would such changes work equally well in the GCC > tree even in the absence of a version update there? If we exclude the AC_PREREQ bumps from 2.64 to 2.69, only zlib has some significant changes. If I exclude the AC_PREREQ change, I am able to regenerate the files using automake 1.11.6 and autoconf 2.64. So it looks ok. > If proposing to change only one tree at a time I think it's important to > take care to minimise the extra costs introduced for people synchronizing > changes between the two trees while the versions are out of sync. To me, > that indicates that the shared files and directories should be fully in > sync before any changes making them deliberately out of sync are applied, > and that changes to non-generated files other than config/override.m4 > should go in both places if they work in both places, so that the > differences immediately after the change is applied are only the required > ones (i.e. config/override.m4 and the generated files), so that anyone > then merging a subsequent change in future knows they expect to get back > to exactly that set of differences and no more. > > (Shared files in the newlib-cygwin tree have been out of sync for a lot > longer. So, while I think that tree also ought to have shared files in > sync, with changes being applied to all three trees (I don't know if > newlib-cygwin has any changes not present in the other trees), I don't > think it's immediately relevant to changes in the binutils-gdb tree right > now.) Understood. Hopefully the series I send will do the job. I don't know if GCC ever plans to switch to git, but using submodules would make it much easier to share that code rather than do manual syncing. Simon