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 559A03858C60 for ; Fri, 31 May 2024 10:40:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 559A03858C60 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 559A03858C60 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=1717152023; cv=none; b=O9v/2JFMMP9mJjeiYkS/BPbzM+kfp6wKo8emqNl5ZTSBXepiAxcmaubrEtH0/KLBGmJH9FIryaVYqBjLl2G/8D8Kwa5wgAv2f3FQ4ly9DfBGC0lN/Zr79s8CZuIbd+S8F803v5Ri7AdwETPjfeXCUOvN6LEjEZ3w/6akLUZBP88= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717152023; c=relaxed/simple; bh=GndpTxU1XJ05VfNMn/xEXOOOEPysHCV7LRtSertCsqg=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=K7Cl5V7sMCTP4lU4cVGn+S+U7C5v4Lg833qGvWUmkziDET2JEhDjuzPioGz4xNIA8aMVTjZTKf7M2B42Vef/6phl+IyLQ3LkP9GVCItawQjCCaYChqUqtbeAMx5F8bGHfVVF4f9vjIM63NxB1/SSp793akCh4AUGRJcMx6mGLgU= 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 1sCzgL-000496-Qx; Fri, 31 May 2024 06:40:21 -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=HUQwtEdFQsfd+90T9bWfK7naCgxat/5FQbOQSVn6zKs=; b=L51W2A7yduU2 /K37PnbC3xKRvbLL+fEpgET+dLW+zxhhjPuk9vkCTv1o+W20Nz6bJqdlxm5YLRtIZ89DpSFtU1SX3 1Apx8F9bph2m5TmH+ue3IAVq0QbAMVUV3KOrLIVaUunnjmEVYTD6xuVl6PVdyAtBHKgkxAb4Rx1Cp UQgCyH+rZyHnBiwb9l/mTFvrgec7I4iODPd8UxJFC+Cmd1XkZoI6Zux10QFVbz2DtOt9BeCn+EpNr o4rShBO6VSehkvABQgb0Bn6idxIJrt2JWkuicYuh5Kp+tc+kR2QiXiomn1a9NdoLBizwf0hzTypT9 KDXFuJfxKrQlKSWguTvQpA==; Date: Fri, 31 May 2024 13:40:05 +0300 Message-Id: <86sexyp8my.fsf@gnu.org> From: Eli Zaretskii To: Andrew Burgess Cc: gdb-patches@sourceware.org, aburgess@redhat.com In-Reply-To: <7d24d630fb96976deb225f1098df2b32e72643bd.1717142725.git.aburgess@redhat.com> (message from Andrew Burgess on Fri, 31 May 2024 09:18:39 +0100) Subject: Re: [PATCHv2 2/5] gdb/doc: allow for version.subst in the source tree References: <7d24d630fb96976deb225f1098df2b32e72643bd.1717142725.git.aburgess@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: Andrew Burgess > Date: Fri, 31 May 2024 09:18:39 +0100 > > In a git checkout of the source code we don't have a version.subst > file in the gdb/doc directory. When building the GDB docs the > version.subst file is generated on demand (we have a recipe for that). > > However, in a release tar file we do include a copy of the > version.subst file in the source tree, as a result the version.subst > recipe will not be run. > > If, in a release build, we force the running of any recipe that > depends on version.subst then we run into a problem. For example, > slightly confusingly, if we 'touch gdb/doc/version.subst' within the > unpacked source tree of a release, then 'make -C gdb/doc GDBvn.texi' > in the build tree, we'll see: > > 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? Alternatively, how about copying version.subst from the source tree to the build tree if it is absent from the build tree? Thanks.