From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id D9A0E3858C56 for ; Mon, 28 Mar 2022 12:04:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D9A0E3858C56 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id AE00C1F37E; Mon, 28 Mar 2022 12:04:31 +0000 (UTC) Received: from murzim.suse.de (murzim.suse.de [10.160.4.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id A5188A3B82; Mon, 28 Mar 2022 12:04:31 +0000 (UTC) Date: Mon, 28 Mar 2022 14:04:31 +0200 (CEST) From: Richard Biener To: Andreas Schwab cc: Richard Biener via Gcc-patches , Tom de Vries , Jakub Jelinek Subject: Re: [PATCH][libgomp, testsuite] Fix hardcoded libexec in plugin/configfrag.ac In-Reply-To: <87czi61e3k.fsf@igel.home> Message-ID: <1n981439-7n40-58p8-776q-8r33rosq338n@fhfr.qr> References: <20220328084543.GA5967@delia.home> <7r86pp10-o5nr-q61-3sor-p4926s5o2r0@fhfr.qr> <87czi61e3k.fsf@igel.home> MIME-Version: 1.0 X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2022 12:04:34 -0000 On Mon, 28 Mar 2022, Andreas Schwab wrote: > On Mär 28 2022, Richard Biener via Gcc-patches wrote: > > > OK in principle, but I have no idea on how portable > > > > $(libexecdir:\$(exec_prefix)/%=%) > > > > is going to be? > > We already require GNU make, don't we? > > > We should aim for POSIX shell compatibility here, whatever that > > exactly is. > > It's not a shell construct. Ah, it's only substituted into Makefile.in - in that case yes, we already require GNU make. If it's evaluated by that and not a subshell of it then it should be indeed fine. Richard.