GSOC draft

[Alex Vong <alexvong1995@gmail.com>]

Hi,

First, sorry for being late. I only realized GSOC application period had
started on Sunday. Here is my proposal: (please note I can only work on
it after the final (after 9/5), I think I will work on it even if
proposal not accepted, just not working full time, some idea may looks
silly to experienced developers since I am still a novince)

Name:
  Alex Vong
Email:
  alexvong1995@gmail.com
Project:
  GNU Guix (Guile based build-tool)
Summary (rationale):
  Free-software is about having freedom to study, distribute, modify
  and re-distribute modified version of software.
  Free-software licenses explicitly grants us these freedom
  under current legal system.
  Internet and code hosting facilities makes it easy to study, dist
  and re-distribute modified version of software to everyone.
  However, it remains hard to modify software.
  One of the reasons is that build systems are complex.
  Consider compiling web browser from source.
  Guix uses the syntactic abstraction capability of scheme
  to make distribution packaging easier.
  We attempt to extend this idea to build system --- starting with a
  conceptually simple make-like build tool implemented in Scheme
  and extends it handles the general case.
Benefits:
  better build system
  ==> easier to build from source / more hack-able software
  ==> attract new contributors
Deliverable:
  An extensible working bare-bone build system in Guile
Plan:
  Idea:
    Autotool separates the configure phase and the build phase,
    in which the configure phase is responsible of probing feature
    provided by system, while the build phase actually does dependency tracking
    and performs the build. This is not optimal since global variables has to
    pass to another phase, one has to make sure to perform the probing
    in the right order. Also, many probing are done regardless whether they
    are needed. This causes performance issue when the result is not cached.
    So, the idea is to integrate the 2 phases,
    so that every declaration is approximately:
      (target (input ...) rule-to-make-target-from-input)
    and rule-to-make-target-from-input should return a Boolean indicates
    if the build succeed.
    For instance we can probe the C compiler using the following rule:
      (gcc () (and=> (return-path-of-gcc-if-exist-else-return-false)
                     (lambda (path) (make-c-compiler path))))
  Proof of concept:
    Incomplete port of Chicken port of PLT (now Racket) make module in Guile.
    See build instruction of <https://gitlab.com/alexvong1995/calc>,
    it uses that incomplete port to build.
  1. Port the Chicken port of PLT (now Racket) make module to Guile.
  2. Rewrite the make macro using syntax-rules.
  3. Add support for feature probing.
  4. Add support for multiple targets. (mid-term?)
  5. Add support for parallel build and opportunistic execution.
  6. Discuss with mentor to proceed.
Communication:
  alexvong1995@gmail.com (personal)
  guix-devel@gnu.org (pubic)
  IRC(?)
  Gitlab repo
Qualification:
  Experience:
    Debian user since Dec 2014
    convert mlucas to use autotool and introduce it to Debian last summer
    basic skill of using dev tools, i.e. git, debbugs, mailing list
    basic skill of programming, i.e. sh, C, autotool, scheme, perl, python
  Need to learn:
   Familiar myself with Guix's internals,
   such as g-exps, bags and store-monad.
   Familiar myself with Guile's macro system,
   i.e. syntax-rules and syntax-case.
   Familiar myself with cmake build system, i.e. the cmake OO features.

Cheers,
Alex