[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using guile as an extension language for GNU make

From: Paul Smith
Subject: Re: Using guile as an extension language for GNU make
Date: Sun, 18 Sep 2011 13:42:45 -0400

On Sun, 2011-09-18 at 14:10 +0200, Ludovic Courts wrote:
> There are two problems I can think of here:
>   - string unquoting is actually more complex than this (recall that
>     ‘object->string’ merely calls ‘write’):
>   - ‘scm_c_eval_string’ can return any Scheme objects, some of which
>     have meaningless representations as strings:
> The latter is probably the most serious question.  I think you would
> really want to constrain expressions passed in $(guile ...) to return
> a string, and not any other type of objects.
> In that case, you could solve the first problem by using (display ...)
> instead of (write ...).

There's no question that the string conversion is a hack: that's mainly
why I'm asking here :-).

I don't want to restrict it to just strings; for example I'd have to
support numbers as well (one of GNU make's main issues right now is that
there is no math capability whatsoever).  I'd like to be able to
possibly convert other things like t and nil (in GNU make's terms,
"false" is the empty string and "true" is any non-empty string).  Maybe
there are other things as well (what about symbols like 'foobar?), I
don't know.

On Sun, 2011-09-18 at 17:30 +0200, Thien-Thi Nguyen wrote:
> The double-quote stripping is kind of hacky.  I would create a port
> and ‘display’ the result of ‘scm_c_eval_string’ to it.  Perhaps you
> could expose a ‘write’ variant, as well, for complete user control.

As above, the double-quote stripping is intensely hacky :-).  I'll look
into the concepts of display and write and see what I can figure out.
Any suggestions or pointers to example code are welcome.

> Similarly for the other funcs.  Overall, i get the vague impression
> that points of exposure could be improved -- made more orthogonal, w/
> fewer (but more powerful) funcs, but that's probably simply my
> ignorance of Make internals speaking.

Well, I'm only exposing two functions, so "fewer" would be ... one, I
guess :-).  It's true that one of them (make-expand) is a superset of
the other; with that single function you could do pretty much anything I
can think of; I'm not sure there's any more powerful capability I can
export.  I'm not sure that's best though.

If anyone has any specific thoughts I'm very interested (that's why I'm

 Paul D. Smith <address@hidden>          Find some GNU make tips at:            
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist

reply via email to

[Prev in Thread] Current Thread [Next in Thread]