unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Pjotr Prins <pjotr.public12@thebird.nl>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: Getting rid of build tools
Date: Fri, 1 Jan 2016 08:16:24 +0100	[thread overview]
Message-ID: <20160101071624.GB19513@thebird.nl> (raw)
In-Reply-To: <87mvst1d1v.fsf@gnu.org>

On Tue, Dec 29, 2015 at 04:37:16PM +0100, Ludovic Courtès wrote:
> The ‘makeLibrary’, ‘compileC’, and other functions used as illustrations
> in the paper would be quite easy to write using our current APIs.

I am thinking about this and maybe I'll give it a go at some point. A
functional approach to buildtools incorporating Hashes makes a lot of
sense. Guile can do composition, so that ticks a box. Guile has
futures, that is another box ticked.

Rather than calculating a dependency graph explitely I would like to
use futures to have the Guile compiler implicitly create a graph which
gets executed in parallel. I am not sure Guile can handle that type of
parallelism at a large scale, even though I find futures in the docs

  https://www.gnu.org/software/guile/manual/html_node/Futures.html

Eelco's Maak paper, interestingly, also mentions the 1 second
limitation of make as a potential source of race conditions. I would
like to have the option of using either time stamps or hash values to
decide whether a compilation step has completed succesfully. SHA
values arguably take longer to compute (actually pfff is a fast
alternative for large data https://github.com/pfff/pfff), but I want
Hash values for the next thing:

I would like to have cluster compilation where jobs are put out in an
opportunistic fashion. I.e., we assume semi-unlimited resources and
place jobs multiple times. The one job that completes first is the one
we take (the others may get killed). This would allow for longer
running jobs to be put out to a heterogeneous environment (think
cluster w. NFS, think cloud, think grid, think phone). For build environents
this could already be of interest, for bioinformatics large data
compute it could be brilliant. It may look wasteful, but truth is most
compute environments are happily idle and have differing bottlenecks
which would help speed up compilation (fastest one wins).

Anyone interested in this project? You know, there are quite a few
workflow initiatives (recent one the CWL) and build tool initiatives
(CMake and sbt, for example, are fairly recent), but I believe they
miss out on real software engineering solutions! Maybe we can get it
right. My question, is any really talented programmer here interested
to work on this and write a prototype? If you are a student we can
even try and get some of the work funded.

  parent reply	other threads:[~2016-01-01  7:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-27  8:23 Getting rid of build tools Pjotr Prins
2015-12-28 15:06 ` Christopher Allan Webber
2015-12-28 19:05   ` Pjotr Prins
2015-12-29  1:47     ` Pjotr Prins
2015-12-29  2:42       ` Pjotr Prins
2015-12-29  7:22         ` Ricardo Wurmus
2015-12-29 15:26           ` Pjotr Prins
2015-12-29 15:37       ` Ludovic Courtès
2015-12-29 15:40         ` Pjotr Prins
2015-12-29 22:21         ` Christopher Allan Webber
2015-12-29 23:41           ` Ludovic Courtès
2016-01-01  7:16         ` Pjotr Prins [this message]
2015-12-29 15:33     ` Ludovic Courtès
2015-12-29 15:39       ` Pjotr Prins
2016-01-06  5:22   ` Pjotr Prins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160101071624.GB19513@thebird.nl \
    --to=pjotr.public12@thebird.nl \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).