Re: Suggestions for contribution for outreachy application

[Ricardo Wurmus]

Hi Sahithi,

> I got familiarized with contributing to package description to packages.
> Can you please suggest me how to proceed further as per discussion in IRC.

As you’ve built the packages you’ve probably noticed that there was a
lot of text output.  Most of these lines are output from tools that are
run when building a package.  A few of these lines are printed by the
build system itself.

Packages in Guix are built in an isolated environment that is spawned by
the “guix-daemon” (written in C++).  When you run “guix build r-abc”,
for example, Guix first computes a so-called derivation corresponding to
the package bound to the variable “r-abc”.  That derivation is stored in
a “.drv” file under “/gnu/store”.  This file contains references to
other derivations and a build script that is run by the daemon in the
isolated environment.

This means that we have two stages: the client-side where the “guix”
command is run, and a build-side that is run inside the build
environment that the daemon provides.  The client-side talks to the
build-side through predefined remote procedure calls; in turn, the
daemon relays its output back to the client through a pipe.

The pipes are set up in “nix/libstore/build.cc”, which is part of the
daemon’s code.

I would like you to look at the Scheme code under “guix/build/” — this
is code for modules that are available on the build-side.  For example
“(guix build gnu-build-system)” provides an implementation of phases for
the GNU build system.  Most other build system reuse the infrastructure
provided by this module.

There you find the output that is produced by the build system itself,
such as the lines “starting phase …” and “phase `build' succeeded…”.

Since the code in “guix/build/” is available on the build side it is an
input to the package build process.  This means that any changes to that
code result in a rebuild of all packages using that code.  In case of
the gnu-build-system that’s pretty much all packages.  So if you feel
like experimenting with that code I would suggest adding a *new* build
system that contains your changes.

I would like you to spend some time browsing the code under
“guix/build/” and tell me what you think the role of the modules to be.
Then think about what you still need to learn in order to plan for the
first task as per the project description:

    As a first task, the intern may want to implement coloured output
    for the printing of daemon messages, while leaving the compiler
    output unchanged.

“daemon messages” should really also include “build system messages”.
What Scheme modules on the client side are involved here?  What parts of
the daemon are important for this task?  Can we get away with only
changing the client side?

These questions don’t necessarily have good answers, but I’d like you to
think about them and let us know what you think.

There are bound to be things you don’t know or that you will find
difficult to understand.  Feel free to ask publicly on IRC or on
address@hidden

I hope that’s enough to get you started on the next segment of your
journey.

--
Ricardo