Group: Guix/GSoC-2017
(Created page with "This page is for tracking ideas and process for participating in Google Summer of Code 2016. = Project ideas for Guix and GuixSD =") |
|||
| Line 2: | Line 2: | ||
= Project ideas for Guix and GuixSD = | = Project ideas for Guix and GuixSD = | ||
| + | |||
| + | == Aarch64 (ARM64) port == | ||
| + | |||
| + | Port Guix to Arm64! See the [http://www.gnu.org/software/guix/manual/html_node/Porting.html porting instructions]. | ||
| + | |||
| + | |||
| + | '''Possible mentors:''' | ||
| + | Ludovic | ||
| + | |||
| + | == Guile based build-tool == | ||
| + | |||
| + | 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 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 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 targets 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 and other Guix members | ||
Revision as of 13:15, 20 January 2017
This page is for tracking ideas and process for participating in Google Summer of Code 2016.
Project ideas for Guix and GuixSD
Aarch64 (ARM64) port
Port Guix to Arm64! See the porting instructions.
Possible mentors:
Ludovic
Guile based build-tool
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 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 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 targets 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 and other Guix members
