From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32124 invoked by alias); 17 Jun 2013 19:53:27 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 32113 invoked by uid 89); 17 Jun 2013 19:53:27 -0000 X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,SPF_PASS autolearn=ham version=3.3.1 Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com) (74.125.82.41) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 17 Jun 2013 19:53:25 +0000 Received: by mail-wg0-f41.google.com with SMTP id y10so3475575wgg.4 for ; Mon, 17 Jun 2013 12:53:23 -0700 (PDT) X-Received: by 10.180.86.38 with SMTP id m6mr5722645wiz.25.1371498803155; Mon, 17 Jun 2013 12:53:23 -0700 (PDT) Received: from localhost ([2.26.194.71]) by mx.google.com with ESMTPSA id k10sm24388871wia.4.2013.06.17.12.53.21 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 17 Jun 2013 12:53:22 -0700 (PDT) From: Richard Sandiford To: "Maciej W. Rozycki" Mail-Followup-To: "Maciej W. Rozycki" ,Alan Modra , , rdsandiford@googlemail.com Cc: Alan Modra , Subject: Re: [PATCH] MIPS: Opcode membership proposal References: <87obway4f5.fsf@firetop.home> <20130617115141.GU21523@bubble.grove.modra.org> Date: Mon, 17 Jun 2013 19:53:00 -0000 In-Reply-To: (Maciej W. Rozycki's message of "Mon, 17 Jun 2013 16:18:45 +0100") Message-ID: <87y5a8o6oj.fsf@talisman.default> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-06/txt/msg00146.txt.bz2 "Maciej W. Rozycki" writes: > This looks a bit convoluted, and frankly I'd prefer if automake supported > true per-object flags with no need to resort to hacks like this, but there > you go. The benefit would be no need to check the rules against generated > ones with each automake upgrade, that is less maintenance burden -- and > the maintenance of our autoconf scriptery has already proved tough even > without that. > > Do you want me to check this alternative or would you prefer to do this > yourself? What do you think about explicitly initialising each field after all? I can easily repurpose the ASE-checking script to do that. I understand the original reason for having optional fields, but the workaround is beginning to feel a bit convoluted. There's also more room for confusion than there was originally, now that we have the ASE field too. Thanks, Richard