unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Tomas Volf <~@wolfsden.cz>
To: jbranso@dismail.de
Cc: guix-devel@gnu.org
Subject: Re: Autodafe is "production" ready
Date: Mon, 3 Jun 2024 15:29:18 +0200	[thread overview]
Message-ID: <Zl3FLie48QP1f3k5@ws> (raw)
In-Reply-To: <9101aa92b331d50f3e70be1e676f7cafa1c1851f@dismail.de>

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

On 2024-06-02 19:02:46 +0000, jbranso@dismail.de wrote:
> Hey Guix!
>
> Have you heard about autodafe?  I just did today.
>
> So it looks like autodafe (1) converts autotools into
> simple makefiles. Quoting from it's hacker's guide (2):
> "The proximate goal of this project is to eliminate autotools's
>  piles of intermediate products and scripts that create a
> jungle in which exploits like the xz crack of 2024 can hide.
>  The wider goal is to abolish the festering complexity sink
> that autotools recipes have become."  Sounds like a fairly cool
> goal eh?

Goal might be cool, but the implementation seems to leave few things to be
desired.  I tried to follow the steps[0] for one project of mine, but got stuck
on 8.  The makemake just hangs, with no CPU usage and no debug output (even with
-ddddddddd).  I killed it after few minutes.

The ./configure seems to lack --program-... family of options, but hopefully
that will be added later (I hope, they are useful).  The renaming of
PACKAGE_VERSION to just VERSION seem somewhat unnecessary (maybe I just missed
the reason?).

EDIT: Ah, if I run `makemake .' instead of just `makemake', it does work right
away.  Interesting choice.  However now I get:

    $ make clean
    Makefile:29: warning: overriding recipe for target 'DEBUG'
    Makefile:28: warning: ignoring old recipe for target 'DEBUG'
    Makefile:30: warning: overriding recipe for target 'DEBUG'
    Makefile:29: warning: ignoring old recipe for target 'DEBUG'
    Makefile:31: warning: overriding recipe for target 'DEBUG'
    Makefile:30: warning: ignoring old recipe for target 'DEBUG'
    Makefile:32: warning: overriding recipe for target 'DEBUG'
    Makefile:31: warning: ignoring old recipe for target 'DEBUG'
    Makefile:33: warning: overriding recipe for target 'DEBUG'
    Makefile:32: warning: ignoring old recipe for target 'DEBUG'
    Makefile:34: warning: overriding recipe for target 'DEBUG'
    Makefile:33: warning: ignoring old recipe for target 'DEBUG'
    Makefile:35: warning: overriding recipe for target 'DEBUG'
    Makefile:34: warning: ignoring old recipe for target 'DEBUG'
    Makefile:36: warning: overriding recipe for target 'DEBUG'
    Makefile:35: warning: ignoring old recipe for target 'DEBUG'
    Makefile:37: warning: overriding recipe for target 'DEBUG'
    Makefile:36: warning: ignoring old recipe for target 'DEBUG'
    Makefile:38: warning: overriding recipe for target 'DEBUG'
    Makefile:37: warning: ignoring old recipe for target 'DEBUG'
    Makefile:39: warning: overriding recipe for target 'DEBUG'
    Makefile:38: warning: ignoring old recipe for target 'DEBUG'
    Makefile:42: warning: overriding recipe for target 'DEBUG'
    Makefile:39: warning: ignoring old recipe for target 'DEBUG'
    Makefile:43: warning: overriding recipe for target 'DEBUG'
    Makefile:42: warning: ignoring old recipe for target 'DEBUG'
    Makefile:44: warning: overriding recipe for target 'DEBUG'
    Makefile:43: warning: ignoring old recipe for target 'DEBUG'
    Makefile:45: warning: overriding recipe for target 'DEBUG'
    Makefile:44: warning: ignoring old recipe for target 'DEBUG'
    Makefile:54: warning: overriding recipe for target 'DEBUG'
    Makefile:45: warning: ignoring old recipe for target 'DEBUG'
    Makefile:55: warning: overriding recipe for target 'DEBUG'
    Makefile:54: warning: ignoring old recipe for target 'DEBUG'
    Makefile:56: *** multiple target patterns.  Stop.

This is where I gave up.

>
> I know that guix has wanted to create a "guile based build
> system" to replace autotools (autodafe is written in
> python 3).  It sounds like Eric's work is moving to
> supplant and/or fix or repace autotools.  Eric is there
> anything Guix can do for you to help you with your goal?
> We do love our guile, so we will probably encourage you
> to use some scheme code.  :)
>
> Richard do you have any advice for Eric in how to "fix or
> replace" autotools?
>
> Ludo, does guix need to do anything to get ready for some
> software wanting to use autodafe  ?  Is there a way we
> could use autodafe to help us get started on a guile based
> build tool?

Not Ludo, but since it still tries to provide the `./configure && make && make
install' interface, should it not mostly just work?  Did you run into any
specific issues?

>
> Thanks,
>
> Joshua
>
>
> 1) https://www.phoronix.com/news/Autodafe-1.0-Released
>
> 2) https://gitlab.com/esr/autodafe/-/blob/master/hacking.adoc
>

Have a nice day,
Tomas Volf

0: https://gitlab.com/esr/autodafe/-/blob/master/de-autoconfiscation.adoc

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      parent reply	other threads:[~2024-06-03 13:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-02 19:02 Autodafe is "production" ready jbranso
2024-06-02 21:39 ` Eric S. Raymond
2024-06-04 18:24   ` jbranso
2024-06-05  0:55     ` Eric S. Raymond
2024-06-03 13:29 ` Tomas Volf [this message]

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=Zl3FLie48QP1f3k5@ws \
    --to=~@wolfsden.cz \
    --cc=guix-devel@gnu.org \
    --cc=jbranso@dismail.de \
    /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).