From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 351B73858414 for ; Mon, 3 Jun 2024 14:22:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 351B73858414 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 351B73858414 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717424569; cv=none; b=oZo+TwkJRF4bLDXDoroFavFzVRyFkx5NRfRW2q0SvWevNKr3tg0MklhNIRbqFQ2yrpKLy0LPaiwGqE77NRxKZC/W/4tJjcJQ+81QnZHZwI+CH1KoP2iWHzaVOVumdXnnKXTDMeTRcrXAyiqsY6dmY8KNnJ9O0kTfKPVNNA76nc8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717424569; c=relaxed/simple; bh=6Cj26WNI2Rzsxuw2jc5nrznjxA9z6OGQT1wrS78bbXg=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=ZwfjQHep45cu82nd4IsfCZj98MojXHjLZ4Tk2m7xMKTK/Sy8RKnMX0YIsF37z7213MuVLvcDAE0SDbInIQ7CZRW9jQO1//l4ejc5mN3JdpbktRfDpemtb6MVr6dsJesuVrh/1tgvDKXwo/xSDBMn0pzeBcc9OQ5hX8phc6F8EnM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1717424566; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1CU9m1fsbsMKndaV+nbEZ65hxQx6j0/8xrSA8ZlRO+0=; b=MQ2s4xSq537jF5YOLqKMdcqBKklUf2r7m9oDTcKCJaPnsx0VYtDgEg6vkdo4i7jPMBS1ht 4nupXjLW84AL+hfFbHM9CSHeViYQuKvwbjhd7q8zGFkt3rkRFb3fnpNHFpoqu9MdPuJ+g6 I3boylE9cyUZ6jXGbx4wtOORgqUdyvk= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-643-3ij5cy3aOfuGrQ6zUOmyMA-1; Mon, 03 Jun 2024 10:22:45 -0400 X-MC-Unique: 3ij5cy3aOfuGrQ6zUOmyMA-1 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-35dc060e68aso2635723f8f.1 for ; Mon, 03 Jun 2024 07:22:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717424563; x=1718029363; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1CU9m1fsbsMKndaV+nbEZ65hxQx6j0/8xrSA8ZlRO+0=; b=uEmOFCHYEPcLmQy0+JTIRORCw3CREDd66fUUeHXUXHtx8mlfla9n7zIHW1eu+sPe+7 XkzUzQrgwvqfZ/MkJ/+/q6LsV1O66r2ykknUCdKoyiH1jguehxaB8rZgO7HqvLzjjsVt QKWow4u4ojgOaZV3MAtb2wO+le90+rW2rDrfOfkVvizbm8ctSV2w2Zz/5/U4QfJblRug MVV7ZG4PcNZ9WbePpOsk/cFXRdaY7adhpQHYtHSeQPC6hUOO/lUOrAqtWNKpJNMV0akf e0Hs1/HyiOvN3D9h12TyX9H7jhIVWWJhrbTVnDUXU3d1xthcqo//EQr4DffeTBmB8IKy zBRQ== X-Gm-Message-State: AOJu0YykdJssUWKPbkk3XSaR724hBOUeLkmg/Ub4YVY8uw+XpHR+bMX/ 9z6xCeVSsQLuXedwqEjPC6+Gi4dpGtSOvh0Oxe17cBrzPBuM9ZMWNaBttmRakOJiWWgHEF0mHtY Q3+aTMmasI0OejtXuOlhSt0Lu6wKAbehNaduAyFLpmOwQsVDUeKb+Ar1YjwNYN5UAiTk= X-Received: by 2002:adf:e946:0:b0:355:45e:11b4 with SMTP id ffacd0b85a97d-35e0f30a068mr6771355f8f.44.1717424563023; Mon, 03 Jun 2024 07:22:43 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFdn7BZZlESqN4nV3YFViaFJiqkcoayb4mo+1VU6xNus0BC6+uoI58v2MGRAsFWiT8U2V05Mg== X-Received: by 2002:adf:e946:0:b0:355:45e:11b4 with SMTP id ffacd0b85a97d-35e0f30a068mr6771331f8f.44.1717424562457; Mon, 03 Jun 2024 07:22:42 -0700 (PDT) Received: from localhost ([31.111.84.186]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-35dd04c0f73sm8852020f8f.18.2024.06.03.07.22.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Jun 2024 07:22:42 -0700 (PDT) From: Andrew Burgess To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: [PATCHv2 2/5] gdb/doc: allow for version.subst in the source tree In-Reply-To: <86sexyp8my.fsf@gnu.org> References: <7d24d630fb96976deb225f1098df2b32e72643bd.1717142725.git.aburgess@redhat.com> <86sexyp8my.fsf@gnu.org> Date: Mon, 03 Jun 2024 15:22:41 +0100 Message-ID: <87cyoyxg0e.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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: Eli Zaretskii writes: >> 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? 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. Another file that has this problem is GDBvn.texi, however, all the commands that consume this file support a '-I dir' command line flag to add a search path, and so for those commands we add '-I $srcdir' so the command will look in the source directory. > Alternatively, how about copying version.subst from the source tree to > the build tree if it is absent from the build tree? That for sure would be possible. We would need to take care to ensure that the modification time on the file wasn't changed, e.g. if we had to copy from one filesystem to another, as GDBvn.texi depends on version.subst, and most of the other doc files depend on GDBvn.texi, and as you pointed out in an earlier email, we don't want to end up triggering a doc rebuild for a release build/install. The other problem is copying/moving the file from the source tree is for parallel builds. Multiple recipes use version.subst, so each of those would I think need to include the logic for copying the file. And would need to ensure that the copy was (a) atomic, and (b) didn't result in an error if another recipe completed before us... otherwise we'd see random errors from a parallel build. I did wonder if we could create a hard dependency on $(builddir)/version.subst, but I have no idea how I could make that work, we need to copy the file from the $(srcdir) only if its up to date, otherwise we need to rebuild the file. And we'd still need to solve the problem that if targets depended on $(builddir)/version.subst which would certainly not exist in a release, then this would trigger a complete rebuild of the docs, which violates a hard requirement. I agree that the solution proposed here is not ideal ... but I'm not sure anything else is better. Thanks, Andrew