guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Call for project proposals: Guix and Outreachy


From: Alex Sassmannshausen
Subject: Re: Call for project proposals: Guix and Outreachy
Date: Sat, 27 Jan 2018 12:45:52 +0100
User-agent: mu4e 0.9.18; emacs 25.3.1

Hi

pelzflorian (Florian Pelz) writes:

> Hello,
>
> On Fri, Jan 26, 2018 at 12:53:37PM +0100, Alex Sassmannshausen wrote:
>> A second step might be a simplified Guile build system, which does not
>> rely on autotools infrastructure.  I believe this was discussed in the
>> past: it would be a "beginners build system" for *Guile only* packages
>> for quick and easy sharing in the Guix community.
>
> By beginners build system, do you mean a Guix build system that just
> copies the modules directory and compiles?

Yes — it would just carry out the steps so that if the Guile package is
a propagated input to anything else, or if it is installed directly, the
Guile package would be available to the Guile executable in that
context.

So the files would simply be installed in the ACTUAL_GUILE_VERSION site
dir & ccache dir.

> Forgive my ignorance as someone who has no deep understanding of
> Guile/Guix, but I think it would be better if even simple Guile only
> packages used a build system like Meson or Autotools.  Even Guile only
> packages should not need Guix or manual copying.  The syntax of
> Autotools is too complicated IMHO, but using a general purpose build
> system like Meson for simple C projects is no more work than listing
> the source files and data files like pkg-config and this should apply
> to Guile projects as well.

I sympathise with your perspective, but this proposed second step would
be quite "selfish" from the perspective of Guix and Guile: it would be a
strong improvement in comparison to what we have now (no widely used
package manager, or project bootstrapping system for Guile), whilst not
committing to infrastructure behind it.

As such it doesn't aim to "care" about non-guix use-cases.  To phrase it
strongly I think Guix is the de-facto Guile package manager, so a good
first step is a simple build environment for that specific package
manager.

We could then gradually build on the tooling to allow a migration path
to autotools.

> That said, a beginners Guix build system for pure Guile projects is
> done much more easily than making simple general purpose build systems
> support Guile.  I’d like to take a look at Meson support for Guile and
> Guile implementations of Ninja and Meson, but I probably can’t/won’t
> commit the time…  Well maybe…

I would be very interested to hear about your further research into this
area for sure! The above stuff is just my opinion so far :-)

Cheers,
Alex



reply via email to

[Prev in Thread] Current Thread [Next in Thread]