unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Catonano <catonano@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: Guix-based build tool
Date: Fri, 20 Apr 2018 08:52:01 +0200	[thread overview]
Message-ID: <CAJ98PDwJo7evkqsUCwbSTG+=YZHU1GEiPF6YhHvGmQ-UKx8oHw@mail.gmail.com> (raw)
In-Reply-To: <CAJ98PDzem0P-gdKGEnhJTRX5obE7Crwk5Kt31=-M=AesuK7MnA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2763 bytes --]

2018-04-19 18:49 GMT+02:00 Catonano <catonano@gmail.com>:

>
>
> 2018-04-18 23:09 GMT+02:00 Ludovic Courtès <ludo@gnu.org>:
>
>> Hello,
>>
>> Christopher Lemmer Webber <cwebber@dustycloud.org> skribis:
>>
>> > While this is a fun idea, I'd still much rather have a guile-based
>> > DSL replacement for autotools type things that's standalone (but maybe
>> > also which can export to shell if need be).
>>
>> Yeah, not depending on Guix would have pros (it’d be more widely
>> applicable), and cons (limited world view).
>>
>> Food for thought!
>>
>> Ludo’.
>>
>>
> there' s this file guix/buid/emacs-utils.scm
>
> it contains utilities to let Emacs byte-compile elisp files
>
> So that' s an Emacs build system and it' s embedded in Guix
>
> My initial idea was to do something similar with Guile
>
> But then I tought that it could have been a stand alone package
>
> Today in the morning I could manage to take a look at this issue
>
> I made a script that visits the file system tree of a project and compiles
> the .scm files
>
> Here' s a short demo
> https://www.youtube.com/watch?v=LaypeR8uw3Q
>
> It doesn' t check the availability of dependencies (other guile packages)
> yet
>
> I was not sure how to achieve that
>
> I saw that Automake generates snippets of bash scripting that try to run
> guile with an expression loading the required module and if that fails then
> the module is not available
>
> The same functionality could be reproduced in Guile
>
> I also saw the guildhall files that Ludo mentioned
>
> So the thing is that the interface towards the user should be like those
> guildhall files
>
> and the interface towards the system should be like the Automake one
>
> But, like Automake, it should only check if a Guile module is reachable on
> the guile load path
>


I am experimenting with this line

(system* "guile" "-c" "(use-modules (commonmark)) (exit ((lambda () 0)))")

If it finds the module it returns 0

Otherwise it returns a different number

I copied some bits for a configure script for a Guile project instrumented
with the Autotools

I could use an example of usage of "status:Exit-val"

The Guile manual says:

     Return the exit status value, as would be set if a process ended
     normally through a call to ‘exit’ or ‘_exit’, if any, otherwise
     ‘#f’.

this is not enouhg for me to understand

In which scenario is thhis function supposed to be used ? In order to do
what ?
An example would be of great help

Anyway: Is this the idiomatic way ?

Or maybe I should use some try catch form wrapping some module loading
instruction ?
Without launching a different guile process ?

Thanks for any hint

[-- Attachment #2: Type: text/html, Size: 4379 bytes --]

  reply	other threads:[~2018-04-20  6:52 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-06  8:58 a blog post Catonano
2018-04-06 22:07 ` Autotools formely: " Pjotr Prins
2018-04-09 15:30   ` Guix-based build tool Ludovic Courtès
2018-04-09 15:53     ` julien lepiller
2018-04-11  8:02     ` Catonano
2018-04-16 16:59     ` Christopher Lemmer Webber
2018-04-18  3:50       ` Chris Marusich
2018-04-18 21:06         ` Ludovic Courtès
2018-04-18 21:09       ` Ludovic Courtès
2018-04-19 16:49         ` Catonano
2018-04-20  6:52           ` Catonano [this message]
2018-04-20  6:58             ` Catonano
2018-04-23 15:53               ` Ludovic Courtès
2018-04-20 20:13             ` Ricardo Wurmus
2018-04-07  3:35 ` a blog post Erik Edrosa
2018-04-07  9:53 ` Hartmut Goebel
2018-04-07 10:46   ` Tobias Geerinckx-Rice
2018-04-07 10:59   ` Catonano
2018-04-09  0:18 ` Chris Marusich

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='CAJ98PDwJo7evkqsUCwbSTG+=YZHU1GEiPF6YhHvGmQ-UKx8oHw@mail.gmail.com' \
    --to=catonano@gmail.com \
    --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).