Group: Guix/GSoC-2024
(create stub) |
|||
| Line 1: | Line 1: | ||
| − | = GNU Guix Google Summer of Code ideas page for 2023 = | + | = GNU Guix Google Summer of Code ideas page for 2024 = |
| + | |||
| + | <!-- | ||
| + | Please make sure to have the 175 hour (medium), 350 hour (large) projects and 90 hour (small) projects labeled correctly on your Ideas list. | ||
| + | --> | ||
| + | |||
| + | == Guile based build-tool for Guix == | ||
| + | |||
| + | Guile-based build tool for advanced software developers who do not want to deal with the complexity of multi-platform deployment and dependency hell. By default the tool runs inside the GNU Guix build system and effectively replaces the likes of autotools, cmake, etc. | ||
| + | |||
| + | Build tools such as automake and cmake are complex beasts. What they try to do is target multiple build environments by generating make files using a complex list of string expansions. Complexity, in general, means hard to understand, change and maintain. The bad thing is that almost every software project has to deal with this complexity to make the software deployable. | ||
| + | |||
| + | What is wrong with these build tools? In short: | ||
| + | |||
| + | 1. Complex - and therefore hard to understand and maintain | ||
| + | |||
| + | 2. Simplistic language - simple string expansion systems are not nice and not DRY | ||
| + | |||
| + | 3. Race conditions - make's time stamps, for example, are not suitable for building across servers | ||
| + | |||
| + | 4. Different combinations of options are badly handled. | ||
| + | |||
| + | 5. No intermediate representation | ||
| + | |||
| + | Alternatives, such as Java ant, Scala sbt, and Ruby rake, try to resolve similar issues but are specialised for their environments. Here we have a *fresh* start of a build tool which should ultimately be able to run complex workflows on multiple servers and make use of opportunistic execution, i.e. jobs may be distributed multiple times and the first one that comes back wins. | ||
| + | |||
| + | We primarily target GNU Guix because Guix already solves the complexity of handling dependencies and software deployment. This simplifies things dramatically because the build system does not have to deal with platform or architecture targets. Even so, in time, we can target out of GNU Guix builds. | ||
| + | |||
| + | '''Mentors:''' Pjotr Prins (pjotr dot public12 at thebird.nl) and other Guix members (through guix-dev mailing list) | ||
| + | |||
| + | Time: 350 hrs (large) | ||
| + | |||
| + | --- | ||
| + | |||
| + | = Ideas from 2023 = | ||
* Decentralized substitute distribution | * Decentralized substitute distribution | ||
| − | * Robustify long-term support for Reproducible Research | + | * Robustify long-term support for Reproducible Research |
| − | * Develop a Web interface to configure Guix System | + | * Develop a Web interface to configure Guix System |
See [https://libreplanet.org/wiki?title=Group:Guix/GSoC-2020] | See [https://libreplanet.org/wiki?title=Group:Guix/GSoC-2020] | ||
Revision as of 17:42, 4 March 2024
Contents
GNU Guix Google Summer of Code ideas page for 2024
Guile based build-tool for Guix
Guile-based build tool for advanced software developers who do not want to deal with the complexity of multi-platform deployment and dependency hell. By default the tool runs inside the GNU Guix build system and effectively replaces the likes of autotools, cmake, etc.
Build tools such as automake and cmake are complex beasts. What they try to do is target multiple build environments by generating make files using a complex list of string expansions. Complexity, in general, means hard to understand, change and maintain. The bad thing is that almost every software project has to deal with this complexity to make the software deployable.
What is wrong with these build tools? In short:
1. Complex - and therefore hard to understand and maintain
2. Simplistic language - simple string expansion systems are not nice and not DRY
3. Race conditions - make's time stamps, for example, are not suitable for building across servers
4. Different combinations of options are badly handled.
5. No intermediate representation
Alternatives, such as Java ant, Scala sbt, and Ruby rake, try to resolve similar issues but are specialised for their environments. Here we have a *fresh* start of a build tool which should ultimately be able to run complex workflows on multiple servers and make use of opportunistic execution, i.e. jobs may be distributed multiple times and the first one that comes back wins.
We primarily target GNU Guix because Guix already solves the complexity of handling dependencies and software deployment. This simplifies things dramatically because the build system does not have to deal with platform or architecture targets. Even so, in time, we can target out of GNU Guix builds.
Mentors: Pjotr Prins (pjotr dot public12 at thebird.nl) and other Guix members (through guix-dev mailing list)
Time: 350 hrs (large)
---
Ideas from 2023
- Decentralized substitute distribution
- Robustify long-term support for Reproducible Research
- Develop a Web interface to configure Guix System
See [1]
Ideas from 2021
- Trusted computing: Goblins for GNU Guix
- Guix Data Service revision processing instrumentation and performance
Ideas from 2020
- Guile based build tool
- GNU Guix system monitor
- Booting via network
- Syntax and semantics of systemd units in the Shepherd
