unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Maxime Devos <maximedevos@telenet.be>
To: guix-devel@gnu.org
Subject: Re: Autotools-generated 'configure' & 'Makefile.in' considered binaries?
Date: Wed, 29 Jun 2022 21:01:10 +0200	[thread overview]
Message-ID: <afe3e0e528e5fca0fa9e033d1389f040a57f2f1d.camel@telenet.be> (raw)

[-- Attachment #1: Type: text/plain, Size: 1867 bytes --]

Small clarification to old discussion:

Hello,

Ludovic Courtès <ludo@gnu.org> writes:

> Hi!
>
> Maxime Devos <maximedevos@telenet.be> skribis:
>
>> Ludovic Courtès schreef op vr 01-04-2022 om 10:58 [+0200]:
>>> As a first milestone, maybe we could start running ‘autoreconf’
more
>>> often, for packages higher in the graph.  We could change the
>>> ‘bootstrap’ build phase to do that unless it’s explicitly turned
off.
>>> It may turn out to be a Sisyphean task though…
>>>
>>> Thoughts?
>>
>> Changing all pre-existing packages, maybe.  But doing this for new
>> packages (reducing review effort) and perhaps when a package is
updated
>> (for purity) should be feasible I think?  Then gradually things
would
>> improve and eventually(TM) doing the switch in the bootstrap phase
may
>> become feasible ...
>
> Yes, we could do that as a first step (in fact it’s already happening
as
> some projects no longer distribute tarballs).
>
> What do maintainers think of that policy?

No strong opinion, but I agree that having a complete development
environment capable of building from the bare sources (e.g. a git tree)
is useful in general.  On the other hand, using tarballs is often
more efficient and practical (it's made to be built by downstream
users,
rather than by developers, so it includes everything needed).  Release
tarballs are also often signed by the projects, which is neat.  So
perhaps we can leave some flexibility there and not make it a hard
rule, but a case of best judgment?

We can both use tarballs _and_ unbundle/regenerate, no need to switch
from tarball to git (though that's one way to do things)!  E.g., adjust
the bootstrap phase to always "autoreconf -vif" and/or add snippets or
post-unpack phases to remove generated or bundled Autotools files.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

             reply	other threads:[~2022-06-29 19:10 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-29 19:01 Maxime Devos [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-03-30 12:04 Autotools-generated 'configure' & 'Makefile.in' considered binaries? Maxime Devos
2022-03-30 14:31 ` Zhu Zihao
2022-03-31 11:17   ` Maxime Devos
2022-03-31 11:19   ` Maxime Devos
2022-03-31 11:22   ` Maxime Devos
2022-03-31 11:27   ` Maxime Devos
2022-03-30 18:55 ` Liliana Marie Prikler
2022-03-30 19:24   ` Maxime Devos
2022-03-31  4:22     ` Liliana Marie Prikler
2022-03-31 11:10       ` Maxime Devos
2022-03-31 18:24         ` Liliana Marie Prikler
2022-03-31 18:31           ` Maxime Devos
2022-03-31 20:11             ` Liliana Marie Prikler
2022-04-01  8:58 ` Ludovic Courtès
2022-04-01 10:03   ` Maxime Devos
2022-04-05 12:06     ` Ludovic Courtès
2022-04-06 16:35       ` Maxim Cournoyer
2022-04-10 20:25         ` Ludovic Courtès
2022-05-02 10:55       ` zimoun
2022-04-01  9:12 ` Jonathan McHugh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=afe3e0e528e5fca0fa9e033d1389f040a57f2f1d.camel@telenet.be \
    --to=maximedevos@telenet.be \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).