From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 6361A39A524F for ; Thu, 6 Jun 2024 11:59:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6361A39A524F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6361A39A524F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717675194; cv=none; b=L03o+ihDtygiWZ14RfEXuCuyUfG6c1d0kvAo4OH4613iouRy7Yn29DsdtL+GTObQ09X3yRJMclAFtgG6MUZgdrwiHoBMhJ1QPBpZdKvDtlOzsZxMvEiLGi9jnAVLzus8O2232h6//G8JshyrJAkUFefNZ4G8w1YSdVQ8SfYBd0U= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717675194; c=relaxed/simple; bh=Q0vCNHFR9/MXCelb1N6ZYg/+oEsfm5THGYi+Gj/TJtc=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=kLtxs06HLA2uJPeJTtgE/prfWgd+tibk2a8UkcQxIELVg6IwUx9iujwkYunmPCCU8RXg+YcGWcbRSyjQFeZOu9InmpduOi8HZa/TWCnBVs016FJwlvNxyU5c00KQn1b+Dr4fCqYSBBIi3w1LZzphtv0o4Gc8KJpGnXUvbrPmPmk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sFBma-0002e0-UI; Thu, 06 Jun 2024 07:59:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=69hqNhsW3wTae922WnXNPQM21Sg0raLJ9s8OkoZKQ/o=; b=dAfOnWiiMLTG 4GM9cxhkD714kgAZNpziW/W+BB6yK+yyJtbXr2U0f3OWOc9F6A2V6mPMTdtmee7M/V9JolZQWB1OI 0L7Rmwa0nUueJsYowXpkYTC8GLB8kHCrNWX+RjYKAeRevg3pUElp99fMPvRBaFzvwByjmqwydAGkf JIClEzXoDA29akL0NcsrLO3crJDkACTQ0kQue10q5Msm7tPI7z4W1FMk8D/tgU3l4vhf0jducmw3U PmB/Kh4HXSxkcEaSo17WVsSxGInyDYuAi1WlD33qhqunMHJAbaJD3JU2jqWwThaR9ns9hqjw0nBkr bgJNOWVZDNpbcYJpMB/0xg==; Date: Thu, 06 Jun 2024 14:59:49 +0300 Message-Id: <86msnygu2y.fsf@gnu.org> From: Eli Zaretskii To: Andrew Burgess Cc: gdb-patches@sourceware.org In-Reply-To: <87cyoyxg0e.fsf@redhat.com> (message from Andrew Burgess on Mon, 03 Jun 2024 15:22:41 +0100) Subject: Re: [PATCHv2 2/5] gdb/doc: allow for version.subst in the source tree References: <7d24d630fb96976deb225f1098df2b32e72643bd.1717142725.git.aburgess@redhat.com> <86sexyp8my.fsf@gnu.org> <87cyoyxg0e.fsf@redhat.com> X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > From: Andrew Burgess > Cc: gdb-patches@sourceware.org > Date: Mon, 03 Jun 2024 15:22:41 +0100 > > Eli Zaretskii writes: > > >> make: Entering directory '/tmp/build/build/gdb/doc' > >> GEN GDBvn.texi > >> sed: can't read version.subst: No such file or directory > >> make: Leaving directory '/tmp/build/build/gdb/doc' > >> > >> The problem is that every reference to version.subst in GDB's Makefile > >> assumes that the version.subst file will always be in the build > >> directory. > >> > >> In this commit I replace direct references to version.subst with a > >> small shell snippet which returns the path to the version.subst file > >> to use. If there is a version.subst file in the build directory then > >> that file is selected, otherwise we return the path to a version.subst > >> file in the source directory. > > > > Why isn't VPATH or vpath enough to solve this nuisance? > > If anything VPATH is the _cause_ of this nuisance! With the VPATH set > as it is, make will check both the build directory and the source > directory. So when we have a rule like: > > some_target : version.subst > some_command version.subst > > make is going to look for the version.subst dependency in both > locations, however, where 'some_command' looks is entirely up to > 'some_command'. In our case for example, the 'sed' command doesn't (to > my knowledge) have a search path command line option, so a command like: > > sed q version.subst > > is only going to search in the build directory. My reading of the node "Recipes/Search" in the GNU Make manual is that if you use automatic variables, such as $^, in the recipe, Make will expand the variable into the full file name including the directory in which it found the file via VPATH search. Can't we use that feature here? IOW, instead of some_target : version.subst some_command version.subst you should use something like some_target : version.subst some_command $< > I agree that the solution proposed here is not ideal ... but I'm not > sure anything else is better. How about the above, assuming it works?