[Bug default/30051] poke-3.0 lacks some .m4 files, causes autoreconf to fail

[slyich at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30051

--- Comment #8 from Sergei Trofimovich <slyich at gmail dot com> ---
(In reply to Arsen Arsenović from comment #7)
> (In reply to Sergei Trofimovich from comment #6)
> > (In reply to Bruno Haible from comment #5)
> > > Who says that running autoreconf on an arbitrary GNU package's tarball is
> > > supported? In general, it is not supported.
> > 
> > If it's unsupported on poke release tarballs then please feel free to close
> > it as INVALID.
> > 
> > Having an equivalent procedure would be nice though. Downstreams have to
> > patch m4 bits from time to time.
> > 
> > And optionally add an explicit error message if it's easy in configure.ac so
> > people would not repeat the mistake again and again when next platform
> > appears and they try `autoreconf -if` again.
> > 
> > > > nixpkgs repository used autoreconf on previous release of poke to get 
> > > > support for new aarch64-darwin and other platforms to get recognized by 
> > > > configure.
> > > 
> > > The tarball now contains the newest config.guess and config.sub. You can
> > > ditch that autoreconf invocation.
> > 
> > Sounds good. That is my current attempt.
> 
> If you can affect nixpkgs, I suggest adopting a practice of not regenerating
> build system files in autotools projects, and, if some are patched (which is
> often necessary, and completely understandable) only re-run the appropriate
> tools (the autoconf manual has a nifty, though incomplete, diagram about
> what produces what:
> https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/
> autoconf#Making-configure-Scripts).

It's not clear to me: are you talking about poke specifically or in for
autoconf-based build systems in general? In general I think I have some basic
understanding how autoconf-based build systems are updated for simpler cases: I
converted a few in the past from complex './bootstrap' scripts to be just
'autoreconf -if'. Specifically to support easy reconfiguration for release
tarballs. Obviously 'poke' does something more complex that does not make it to
Just Work.

> Of course, if building from Git snapshots, you ought to run ``./bootstrap''.

Not sure if it is relevant here. I'd prefer a release tarball not to rely on
internet access to regenerate the build system to apply local patch as long as
we have needed dependencies present. `./bootstrap` is not present in the
release tarball either, thus it's probably not the way to go here.

> You can safely bump config.{status,guess}, as both are just invocable
> programs that configure scripts run, and do not get inlined in any other
> files.

Is it an advice for this specific case or for general case? I think specific
case is not as relevant as files are fresh enough.

For general case your link says that 'autoreconf' is the tool that refreshes
those files unless I'm misreading it. I'd rather not reimplement subset of
autoconf, automake, or local .m4 macro logic by tracking what needs to be
updated for individual files, to maintain file timestamps to avoid build
system's regeneration loops and whatnot.

I did not get the clear answer above what is the supported way to regenerate
build system in the tarball after the change. #comment5 implies autoreconf is
not supported (and it is very surprising to me). I assume anything similar to
that process is equally unsupported: be it 'autoconf' run, 'autoheader'
regeneration or subset of file copies.

-- 
You are receiving this mail because:
You are on the CC list for the bug.