Re: question was: What do we think about always autoreconfing? was: Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal))
On Mon, 2021-04-19 at 09:27 +0200, Ondrej Dubaj wrote: > > > On Fri, Apr 16, 2021 at 3:30 PM David Cantrell > wrote: > > On Tue, Apr 13, 2021 at 11:26:24AM +0100, Richard W.M. Jones wrote: > > >Hijacking this thread originally about > > >https://fedoraproject.org/wiki/Changes/Autoconf_271 > > > > > >What is the current thinking in Fedora about always running > > >"autoreconf -i" during builds that use autotools? > > > > I think we are likely to see the least problems for projects that > > created their configure.ac files using autoscan. For projects that > > constructed them manually or in other ways, we'll likely see some > > fallout. I would encourage maintainers to work towards fixing > > these > > things and contributing them back upstream. Still, we would need > > to > > provide a way to disable the autoreconf step for particular > > problematic packages. > > > > Some projects provide their own autotools macros and wrappers > > around > > autoreconf. For example, Xfce either provides or provided xdt- > > autogen > > as a wrapper to run autoreconf with the Xfce-specific macros and > > other > > defines available. If it's best to rerun xdt-autogen in these > > cases, > > how could we handle that in the spec file so it runs the correct > > 'autoreconf' command? > > > > >The cons of always autoreconfing are that it slows down builds, > > >sometimes considerably. It also could fail - I noticed that > > autoconf > > >2.71 has several incompatibilities with the most widely used > > autoconf > > >(2.69). > > > > I think the failures will be the most frustrating part of this > > rather > > than the build time. An FAQ or something of how to fix common > > failures for 2.71 would be useful for contributors. > > > > > Document with common failures and fixes already exists [1]. Also > multiple ways of testing are documented in the change proposal [2], > where the link to the document [1] is present. > > Updating autoconf to version 2.71 is a hard process, we are doing our > best to make it as fluent as possible. There is a copr created for > testing, bugs in bugzilla created (with link to change proposal) for > failing components and we are actively moving things forward. > > Hopefully it will be enough to make this possible. > > [1] > https://docs.google.com/document/d/1SAGTJZEF9z_nkHMbXTF-YTTvKRja7ygfOOMzl-DYBSk/edit > I almost missed this precious document, in my opinion it should go to the fedoraproject wiki pages along [2] The document covers almost all the problems that I found "if test "$ac_test_CFLAGS" = set" , stopped to work what is the correct replacement ? "if test -z $CFLAGS; then" or "if test $ac_test_CFLAGS; then" this second option was found here [3] [3] https://chromium.googlesource.com/external/github.com/Distrotech/autoconf/+/76754e04fce5f6a7701bec57b057020585df2ae3%5E%21/ > [2] https://fedoraproject.org/wiki/Changes/Autoconf_271#How_To_Test > > > > > > Thanks, > > > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > Do not reply to spam on the list, report it: > > https://pagure.io/fedora-infrastructure -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: What do we think about always autoreconfing? (was: Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal))
On Fri, Apr 16, 2021 at 3:30 PM David Cantrell wrote: > On Tue, Apr 13, 2021 at 11:26:24AM +0100, Richard W.M. Jones wrote: > >Hijacking this thread originally about > >https://fedoraproject.org/wiki/Changes/Autoconf_271 > > > >What is the current thinking in Fedora about always running > >"autoreconf -i" during builds that use autotools? > > I think we are likely to see the least problems for projects that > created their configure.ac files using autoscan. For projects that > constructed them manually or in other ways, we'll likely see some > fallout. I would encourage maintainers to work towards fixing these > things and contributing them back upstream. Still, we would need to > provide a way to disable the autoreconf step for particular > problematic packages. > > Some projects provide their own autotools macros and wrappers around > autoreconf. For example, Xfce either provides or provided xdt-autogen > as a wrapper to run autoreconf with the Xfce-specific macros and other > defines available. If it's best to rerun xdt-autogen in these cases, > how could we handle that in the spec file so it runs the correct > 'autoreconf' command? > > >The cons of always autoreconfing are that it slows down builds, > >sometimes considerably. It also could fail - I noticed that autoconf > >2.71 has several incompatibilities with the most widely used autoconf > >(2.69). > > I think the failures will be the most frustrating part of this rather > than the build time. An FAQ or something of how to fix common > failures for 2.71 would be useful for contributors. > Document with common failures and fixes already exists [1]. Also multiple ways of testing are documented in the change proposal [2], where the link to the document [1] is present. Updating autoconf to version 2.71 is a hard process, we are doing our best to make it as fluent as possible. There is a copr created for testing, bugs in bugzilla created (with link to change proposal) for failing components and we are actively moving things forward. Hopefully it will be enough to make this possible. [1] https://docs.google.com/document/d/1SAGTJZEF9z_nkHMbXTF-YTTvKRja7ygfOOMzl-DYBSk/edit [2] https://fedoraproject.org/wiki/Changes/Autoconf_271#How_To_Test > Thanks, > > -- > David Cantrell > Red Hat, Inc. | Boston, MA | EST5EDT > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: What do we think about always autoreconfing? (was: Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal))
On Tue, Apr 13, 2021 at 11:26:24AM +0100, Richard W.M. Jones wrote: Hijacking this thread originally about https://fedoraproject.org/wiki/Changes/Autoconf_271 What is the current thinking in Fedora about always running "autoreconf -i" during builds that use autotools? I think we are likely to see the least problems for projects that created their configure.ac files using autoscan. For projects that constructed them manually or in other ways, we'll likely see some fallout. I would encourage maintainers to work towards fixing these things and contributing them back upstream. Still, we would need to provide a way to disable the autoreconf step for particular problematic packages. Some projects provide their own autotools macros and wrappers around autoreconf. For example, Xfce either provides or provided xdt-autogen as a wrapper to run autoreconf with the Xfce-specific macros and other defines available. If it's best to rerun xdt-autogen in these cases, how could we handle that in the spec file so it runs the correct 'autoreconf' command? The cons of always autoreconfing are that it slows down builds, sometimes considerably. It also could fail - I noticed that autoconf 2.71 has several incompatibilities with the most widely used autoconf (2.69). I think the failures will be the most frustrating part of this rather than the build time. An FAQ or something of how to fix common failures for 2.71 would be useful for contributors. Thanks, -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: What do we think about always autoreconfing? (was: Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal))
On Tue, 13 Apr 2021 at 11:27, Richard W.M. Jones wrote: > Hijacking this thread originally about > https://fedoraproject.org/wiki/Changes/Autoconf_271 > > What is the current thinking in Fedora about always running > "autoreconf -i" during builds that use autotools? > 1) "autoreconf -i" is not enough. It needs to be executed "autoreconf -fi" and to have proper visibility reconfigure issues should be executed "autoreconf -fiv" 2) Looks like still no one performed experiment of rebuilding all existing packages with %configure macro in spec by execute: $ for i in *.src.rpm; do rpmbuild --rebuild -D "_configure 'autoreconf -fiv; configure'" $i; done To check which Fedora packages are failing in the build environment with autoconf 2.71. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: What do we think about always autoreconfing? (was: Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal))
On 4/13/21 12:26 PM, Richard W.M. Jones wrote: Hijacking this thread originally about https://fedoraproject.org/wiki/Changes/Autoconf_271 What is the current thinking in Fedora about always running "autoreconf -i" during builds that use autotools? IMO, it's naive wishful thinking, applicable to trivial packages. Most non-trivial packages require specific versions. Also, in general, it's not advisable to regenerate auto*tools generated sources at all. I am aware, this thought has become unpopular, because the autotools have been mostly "dormant" in recent years, so people are not used to face such problems, anymore. In Debian it's been recommended for a long time: https://wiki.debian.org/Autoreconf Well, ... Debian's mistake. It also could fail - I noticed that autoconf 2.71 has several incompatibilities with the most widely used autoconf (2.69). This is only the tip of the proverbial "iceberg". autoconf > 2.69 is pretty imcompatible and bugged. Ralf ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
What do we think about always autoreconfing? (was: Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal))
Hijacking this thread originally about
https://fedoraproject.org/wiki/Changes/Autoconf_271
What is the current thinking in Fedora about always running
"autoreconf -i" during builds that use autotools?
In Debian it's been recommended for a long time:
https://wiki.debian.org/Autoreconf
I maintain a few packages where I attempt to toggle autoreconfing
based on whether patches touch build files. If a downstream patch is
applied which touches any of configure.ac, Makefile.am, or several
other files, then the build will attempt to run autoconf/automake and
usually fail. These packages have:
# If there are patches which touch autotools files, set this to 1.
%global patches_touch_autotools %{nil}
%if 0%{patches_touch_autotools}
BuildRequires: autoconf, automake, libtool
%endif
%prep
...
%if 0%{patches_touch_autotools}
autoreconf -i
%endif
This is a kind of optimal solution, but also hard to get right - I
often find myself forgetting to set the %global correctly after
applying or removing downstream patches.
The cons of always autoreconfing are that it slows down builds,
sometimes considerably. It also could fail - I noticed that autoconf
2.71 has several incompatibilities with the most widely used autoconf
(2.69).
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
