unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Alex Sassmannshausen <alex.sassmannshausen@gmail.com>
To: Amirouche Boubekki <amirouche.boubekki@gmail.com>
Cc: Arne Babenhauserheide <arne_bab@web.de>,
	guile-devel <guile-devel@gnu.org>
Subject: Re: FOSDEM 2019
Date: Wed, 06 Feb 2019 15:42:48 +0000	[thread overview]
Message-ID: <87mun8ditj.fsf@gmail.com> (raw)
In-Reply-To: <CAL7_Mo8Ya5N+tUJpb56w+FSpbg=k_=y043is5CUiELxOcCu6Dw@mail.gmail.com>


Hi Amirouche

Amirouche Boubekki writes:

> Le mer. 6 févr. 2019 à 14:47, Alex Sassmannshausen <alex.sassmannshausen@gmail.com> a écrit :
>
>  >  - Janneke mentioned the new guile build system in guix for simpler
>  >    guile packages and I think that's pretty great.  Likewise there was
>  >    some mention of some sort of you-don't-have-to-use-autotools build
>  >    system and I don't remember what it's name was.  (BTW, I continue to
>  >    believe that "Guix is and should be Guile's package mangager".)
>
>  I was unaware that we had a guile build system in Guix.
>
> What is it?

I may be misunderstanding — so feel free to clarify!

The build system in Guix would be a value that can be declared in the
`build-system' field of package definitions.  It's basically what tells
Guix what steps need to be performed to build and install an
application.

Guile libraries and applications currently need to use the GNU Build
System, or the trivial build system, with some additional steps that
need to be added by the packager.

If we had a build system, we could simply stick the `guile-build-system'
value in the `build-system' field.

>  In the past I was the one who argued strongly for the build system and
>  for the no-autotools approach — I believe in the context of outreachy.
>  Unfortunately I was unable to make that part a reality.
>
>  Even so, I have been developing a solution that is part of this
>  discussion in the form of Guile Hall, which is a project manager for
>  Guile with strong integration with Guix & Autotools.
>
> guile hall can be found here https://gitlab.com/a-sassmannshausen/guile-hall

Thank you for adding that link.  I forgot to add that!

>  As you can see, I have a horse in this race.  I would be very interested
>  in collaborating with others who feel strongly about this part of the
>  Guile/Guix user journey — either on improvements to Hall, Guix or on
>  other tooling.
>
> Talking about tools and build systems, what do you think of https://waf.io/?

I have heard about it before, but to be honest I haven't engaged with
it.  For me, my engagement with build systems is a necessary evil.  I
want to do the right thing, but really I want to engage with them as
little as possible.

Hackers much more knowledgeable and experienced than I have persuasively
argued for the benefits of the Autotools infrastructure, which also is
the "blessed" GNU system.

This is why I decided to have Hall build Autotools infrastructure.

Sorry, this answer might not have been what you are looking for, but the
truth is I don't even know enough about build systems to be able to
evaluate their merits.

There has been talk in the past about Autotools replacements or Guile
build systems etc. but in the meantime I wanted to get something out
there, in a rather unlisp-y fashion perhaps, that is worse than better
(https://www.dreamsongs.com/WorseIsBetter.html).

Best wishes,

Alex



  parent reply	other threads:[~2019-02-06 15:42 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-03 21:34 FOSDEM 2019 Mikael Djurfeldt
2019-02-03 23:13 ` Arne Babenhauserheide
2019-02-04  5:21   ` Nala Ginrut
2019-02-05 21:25   ` Christopher Lemmer Webber
2019-02-06 13:46     ` Alex Sassmannshausen
2019-02-06 15:22       ` Amirouche Boubekki
2019-02-06 15:33         ` Amirouche Boubekki
2019-02-06 15:42         ` Alex Sassmannshausen [this message]
2019-02-06 21:03           ` Ricardo Wurmus
2019-02-06 22:09             ` Alex Sassmannshausen
2019-02-26  8:57             ` swedebugia
2019-02-06 20:40         ` Arne Babenhauserheide
2019-02-05 21:26   ` Christopher Lemmer Webber
2019-02-04 13:06 ` Amirouche Boubekki
2019-02-04 14:44 ` Ludovic Courtès
2019-02-04 18:01   ` Jan Nieuwenhuizen
2019-02-05 11:09   ` Amirouche Boubekki
2019-02-05 16:58     ` Ludovic Courtès
2019-02-06  0:31       ` Nala Ginrut
2019-02-06 12:59         ` Ludovic Courtès
2019-02-06 19:09           ` Amirouche Boubekki
2019-02-06  0:37       ` Matt Wette
2019-02-06  0:56         ` Nala Ginrut
2019-02-06  1:40       ` Amirouche Boubekki
2019-02-05  2:30 ` Matt Wette
  -- strict thread matches above, loose matches on Subject: below --
2018-08-21 13:33 Manolis Ragkousis
2018-08-21 17:57 ` Ricardo Wurmus
2018-08-22 16:27   ` Andy Wingo
2018-08-22  2:33 ` Mike Gran
2018-08-23  0:08 ` Mike Gran
2018-08-24 12:23 ` Christopher Lemmer Webber
2018-08-29 21:08   ` Ludovic Courtès

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://www.gnu.org/software/guile/

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

  git send-email \
    --in-reply-to=87mun8ditj.fsf@gmail.com \
    --to=alex.sassmannshausen@gmail.com \
    --cc=amirouche.boubekki@gmail.com \
    --cc=arne_bab@web.de \
    --cc=guile-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.
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).