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.133.124]) by sourceware.org (Postfix) with ESMTPS id 0E7623858D35 for ; Tue, 29 Aug 2023 15:45:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0E7623858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1693323926; h=from:from:reply-to: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=yKdAUoQumWRDJmKpSl1EQmCOycGipx/qmeWtxGW4sVs=; b=ZGYQg35LEyHLNSPElbPHjso/javjHtOjfUm6VZWP2dsXLkIfv1HBu2VK1obEfe8YQylcVb jY8XLHh1azQIUNqkTjsQBM3rN3PIDYBnjwz8saaW3cG97XF3DK/z47wty9uTKlhlJRfVee cYtoj15w8jc0ATZAYcRJFxC4BfHU1KY= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-164-Ukj3HXrzOy-SjMhzH2ZRAA-1; Tue, 29 Aug 2023 11:45:23 -0400 X-MC-Unique: Ukj3HXrzOy-SjMhzH2ZRAA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2C8FE80027F; Tue, 29 Aug 2023 15:45:23 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.224.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C22785CC01; Tue, 29 Aug 2023 15:45:22 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 37TFjKqD3866425 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 29 Aug 2023 17:45:21 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 37TFjKDY3866424; Tue, 29 Aug 2023 17:45:20 +0200 Date: Tue, 29 Aug 2023 17:45:20 +0200 From: Jakub Jelinek To: Nick Clifton Cc: gcc-patches@gcc.gnu.org, gdb-patches@sourceware.org, binutils@sourceware.org Subject: Re: RFC: Top level configure: Require a minimum version 6.8 texinfo Message-ID: Reply-To: Jakub Jelinek References: <87wmxd50xj.fsf@redhat.com> MIME-Version: 1.0 In-Reply-To: <87wmxd50xj.fsf@redhat.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-9.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, Aug 29, 2023 at 04:21:44PM +0100, Nick Clifton via Gcc-patches wrote: > Currently the top level configure.ac file sets the minimum required > version of texinfo to be 4.7. I would like to propose changing this > to 6.8. > > The reason for the change is that the bfd documentation now needs at > least version 6.8 in order to build[1][2]. Given that 4.7 is now > almost 20 years old (it was released in April 2004), updating the > requirement to a newer version does seem reasonable. On the other > hand 6.8 is quite new (it was released in March 2021), so a lot of > systems out there may not have it. > > Thoughts ? I think that is too new. We still allow building gcc e.g. with GCC 4.8 from ~ 10 years ago and I think various boxes where people regularly build gcc will have similarly old other tools. So, bumping requirement from ~ 20 years old tools to ~ 10 years old tools might be ok, but requiring ones at most 2 years old will be a nightmare, especially if gcc itself doesn't have such a requirement. Sure, we have requirements on newer gmp/mpfr/libmpc etc., but every extra requirement means some extra work for lots of people. So, either revert those bfd/*.texi changes, or make them somehow conditional on the makeinfo version, or perhaps have this texinfo version requirement only inside of bfd configure, or, if you really want to do it in toplevel configure, make it dependent on whether bfd/ subdirectory is present (if not, keep the old requirement, otherwise newer)? > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=30703 > [2] https://sourceware.org/pipermail/binutils/2023-February/125943.html > > Suggested patch: > > diff --git a/configure.ac b/configure.ac > index 01cfd017273..10bfef1c6c5 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -3678,10 +3678,10 @@ case " $build_configdirs " in > *" texinfo "*) MAKEINFO='$$r/$(BUILD_SUBDIR)/texinfo/makeinfo/makeinfo' ;; > *) > changequote(,) > - # For an installed makeinfo, we require it to be from texinfo 4.7 or > + # For an installed makeinfo, we require it to be from texinfo 6.8 or > # higher, else we use the "missing" dummy. > if ${MAKEINFO} --version \ > - | egrep 'texinfo[^0-9]*(4\.([7-9]|[1-9][0-9])|[5-9]|[1-9][0-9])' >/dev/null 2>&1; then > + | egrep 'texinfo[^0-9]*(6\.([8-9]|[1-9][0-9])|[7-9]|[1-9][0-9])' >/dev/null 2>&1; then > : > else > MAKEINFO="$MISSING makeinfo" Jakub