From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4409 invoked by alias); 17 Jun 2013 15:18:57 -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 4398 invoked by uid 89); 17 Jun 2013 15:18:56 -0000 X-Spam-SWARE-Status: No, score=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL autolearn=ham version=3.3.1 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 17 Jun 2013 15:18:55 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1UobCn-0005pi-PK from Maciej_Rozycki@mentor.com ; Mon, 17 Jun 2013 08:18:53 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jun 2013 08:18:53 -0700 Received: from [172.30.64.32] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Mon, 17 Jun 2013 16:18:51 +0100 Date: Mon, 17 Jun 2013 15:18:00 -0000 From: "Maciej W. Rozycki" To: Alan Modra CC: Subject: Re: [PATCH] MIPS: Opcode membership proposal In-Reply-To: <20130617115141.GU21523@bubble.grove.modra.org> Message-ID: References: <87obway4f5.fsf@firetop.home> <20130617115141.GU21523@bubble.grove.modra.org> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-06/txt/msg00144.txt.bz2 On Mon, 17 Jun 2013, Alan Modra wrote: > > +micromips-opc.lo: micromips-opc.c > > + $(LTCOMPILE) $(NO_WMISSING_FIELD_INITIALIZERS) -c -o $@ $< > > + > > +mips-opc.lo: mips-opc.c > > + $(LTCOMPILE) $(NO_WMISSING_FIELD_INITIALIZERS) -c -o $@ $< > > + > > +mips16-opc.lo: mips16-opc.c > > + $(LTCOMPILE) $(NO_WMISSING_FIELD_INITIALIZERS) -c -o $@ $< > > + > > This patch resulted in no dependencies being generated for the mips > opcode files, causing my regression tests to fail spectacularly from > time to time. I finally got around to looking into the problem. Oops, sorry about causing this regression -- I didn't notice it -- and thanks for addressing it. > * Makefile.am (mips-opc.lo): Add rules to create automatic > dependency files. Pass archdefs. > (micromips-opc.lo, mips16-opc.lo): Likewise. > * Makefile.in: Regenerate. > > Index: opcodes/Makefile.am > =================================================================== > RCS file: /cvs/src/src/opcodes/Makefile.am,v > retrieving revision 1.172 > diff -u -p -r1.172 Makefile.am > --- opcodes/Makefile.am 6 Feb 2013 23:22:25 -0000 1.172 > +++ opcodes/Makefile.am 17 Jun 2013 11:06:21 -0000 > @@ -573,13 +573,43 @@ $(srcdir)/rl78-decode.c: @MAINT@ $(srcdi > ./opc2c$(EXEEXT_FOR_BUILD) $(srcdir)/rl78-decode.opc > $(srcdir)/rl78-decode.c > > micromips-opc.lo: micromips-opc.c > - $(LTCOMPILE) $(NO_WMISSING_FIELD_INITIALIZERS) -c -o $@ $< > +if am__fastdepCC > + $(LTCOMPILE) $(NO_WMISSING_FIELD_INITIALIZERS) \ > + -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ @archdefs@ $< > + mv -f $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo > +else > +if AMDEP > + source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@ > + DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@ > +endif > + $(LTCOMPILE) $(NO_WMISSING_FIELD_INITIALIZERS) -c -o $@ @archdefs@ $< > +endif > > mips-opc.lo: mips-opc.c > - $(LTCOMPILE) $(NO_WMISSING_FIELD_INITIALIZERS) -c -o $@ $< > +if am__fastdepCC > + $(LTCOMPILE) $(NO_WMISSING_FIELD_INITIALIZERS) \ > + -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ @archdefs@ $< > + mv -f $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo > +else > +if AMDEP > + source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@ > + DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@ > +endif > + $(LTCOMPILE) $(NO_WMISSING_FIELD_INITIALIZERS) -c -o $@ @archdefs@ $< > +endif > > mips16-opc.lo: mips16-opc.c > - $(LTCOMPILE) $(NO_WMISSING_FIELD_INITIALIZERS) -c -o $@ $< > +if am__fastdepCC > + $(LTCOMPILE) $(NO_WMISSING_FIELD_INITIALIZERS) \ > + -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ @archdefs@ $< > + mv -f $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo > +else > +if AMDEP > + source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@ > + DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@ > +endif > + $(LTCOMPILE) $(NO_WMISSING_FIELD_INITIALIZERS) -c -o $@ @archdefs@ $< > +endif > > $(srcdir)/rx-decode.c: @MAINT@ $(srcdir)/rx-decode.opc opc2c$(EXEEXT_FOR_BUILD) > ./opc2c$(EXEEXT_FOR_BUILD) $(srcdir)/rx-decode.opc > $(srcdir)/rx-decode.c Hmm, this looks horribly tied to automake's internals to me and I am afraid is bound to break as soon as automake maintainers decide to change how the rules are generated. I know that this is going to be a pain, but I wonder if it could be rewritten in a way that is portable across automake versions, that is only relying on automake's published interface. There is a way to request per-object compilation flags described in the `Per-Object Flags Emulation' section of the automake manual. It involves auxiliary convenience libraries (aka `ar' archives) and I used it successfully in the past, albeit with program targets only rather than libtool libraries. I do hope with little effort that can be adapted for the latter case too. 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? Maciej