From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.lisp.guile.user Subject: Re: Using guile as an extension language for GNU make Date: Tue, 20 Sep 2011 22:39:43 +0200 Message-ID: <878vpjj6cw.fsf@ambire.localdomain> References: <1316304616.28907.118.camel@homebase> <87wrd5x404.fsf@ambire.localdomain> <1316374080.28907.163.camel@homebase> <87sjntwf29.fsf@ambire.localdomain> <1316445274.28907.174.camel@homebase> <87iponjihq.fsf@ambire.localdomain> <1316539888.28907.201.camel@homebase> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: dough.gmane.org 1316551287 31547 80.91.229.12 (20 Sep 2011 20:41:27 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 20 Sep 2011 20:41:27 +0000 (UTC) Cc: guile-user@gnu.org To: psmith@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Sep 20 22:41:23 2011 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1R6784-0002EJ-HC for guile-user@m.gmane.org; Tue, 20 Sep 2011 22:41:20 +0200 Original-Received: from localhost ([::1]:58894 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6783-0007No-W6 for guile-user@m.gmane.org; Tue, 20 Sep 2011 16:41:19 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:58303) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6781-0007Ne-4z for guile-user@gnu.org; Tue, 20 Sep 2011 16:41:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R677z-0000fw-I0 for guile-user@gnu.org; Tue, 20 Sep 2011 16:41:17 -0400 Original-Received: from smtp205.alice.it ([82.57.200.101]:50001) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R677u-0000ez-Ti; Tue, 20 Sep 2011 16:41:11 -0400 Original-Received: from ambire.localdomain (95.249.37.120) by smtp205.alice.it (8.5.124.08) id 4DE6347509D6F900; Tue, 20 Sep 2011 22:41:09 +0200 Original-Received: from ttn by ambire.localdomain with local (Exim 4.69) (envelope-from ) id 1R676W-00018o-0z; Tue, 20 Sep 2011 22:39:44 +0200 In-Reply-To: <1316539888.28907.201.camel@homebase> (Paul Smith's message of "Tue, 20 Sep 2011 13:31:28 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 82.57.200.101 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:8819 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable () Paul Smith () Tue, 20 Sep 2011 13:31:28 -0400 I showed the code in my original post, but the way I've implemented it is that the argument to the make "guile" function (that is, everything after the "$(guile " to the closing paren--it's handy that Guile parens will virtually always match, but you can use ${guile ...} instead if you prefer), will first be make-expanded (so all verbatim instances of "$" in the Guile script will need to be escaped as "$$"--it doesn't seem like Guile uses "$" very much so this shouldn't be too painful) and then the result will be passed to scm_c_eval_string(). Ah, ok. As far as I understand it, that means the Guile program can be as complex as you want. HOWEVER, you will need to use backslashes to escape newlines in your example above. Distasteful. You can also use make's define/endef if you want to write long Guile programs and avoid the need for backslashes, then you can run $(guile $(DEFINEDVARIABLE)). Then make will convert the SCM returned from scm_c_eval_string() into a string buffer as discussed below etc., and use that as the expansion of the $(guile ...) function. OK, sounds much better. > - Would stuff like =E2=80=98normalize=E2=80=99 and =E2=80=98trace=E2= =80=99 be provided (builtin)? You are now running far beyond my understanding of Guile :-). If it works in the environment I describe above then it will work. If not, then I'll need more details. However I just tried your example above and I got an error "unbound variable: trace" so there's something missing here. I'll have to read about that. Yeah, =E2=80=98trace=E2=80=99 does not exist. I think it (and other facili= ties) should be defined by make, by (perhaps lazily, to avoid penalizing non-users) loading a file, say, builtin.scm. The minimum contents might be: (define-module (make-user) ;; builtins from C ;; #:use-module (make-internals) #:use-module (guile-user) #:use-module (srfi srfi-13) #:use-module (srfi srfi-14)) =20=20 (define DEBUG? (getenv "DEBUG")) ;; TODO: Set based on =E2=80=98-d=E2=80=99 exposed from C. =20=20 (define (fse s . args) (apply simple-format (current-error-port) s args)) =20=20 (define (trace name . etc) (cond (DEBUG? (fse "hey: ~A ~S~%" name etc)))) =20=20 ;;; Add other convenience procs here. Note that this doesn't export anything; the evaluation would need to arrange to do its work with this as the "current module". But, that's just an idea. You can also =E2=80=98(define-module (guile-user) ...)=E2=80= =99 to keep things simple initially... > - What happens if the stuff inside the double quotes includes > $(call...) or $(eval...)? What about those constructs elsewhere? [standard expansion explanation] OK, got it. I suppose it's possible that we could introduce a new, more advanced parser for the guile function that took into account quotes. But I'm nervous about this: it's completely different than other expansions, and it might be just as annoying as doing it the other way. I agree, that's probably to be avoided. > (define (as-string x) ...) > (define (space-sep x) ...) Heh, cute! I haven't done much Lisp of any kind since I wrote a number of elisp packages, years ago. I think I'll have to dust off my Scheme. Yes, don't delay, just do it! Playing some more, i realized the above version 0.0 is suboptimal. Below is version 0.1 -- perhaps it could go into builtins.scm. Maybe as an exercise, but patsubst IS a core feature, in that it has existed forever and there are thousands of makefiles that use it... basically rewriting existing capabilities so they're not available if Guile is not present changes things from "GNU make with Guile optional" to "GNU make with Guile required". I'm not ready to go there. Right, i see the sticking point is the "re" in "rewriting". For me, that "re" does not imply replacement, just iteration. My "playing at working" MO: i skim working code and write (and integrate side-by-side-wise) a workalike implementation based on what i think are the original's intended design, then compare the two under load, selecting the impl to use based on some runtime switch (typically an env var). This leads to better questions as understanding (and/or frustration) grows. Even if the second impl is inferior (ends up trashed or permanently disabled), i gain something from the experience (although i lose time, oh well). Anyway, that's what i was suggesting. I chose =E2=80=98patsubst=E2=80=99 because its design seems straightforward= ; it would be easy to validate another impl. No worries, i shall harp no more on this. ____________________________________________________ --=-=-= Content-Type: application/x-scheme Content-Disposition: attachment; filename=procs-for-gnu-make-hacking.scm Content-Transfer-Encoding: base64 CihkZWZpbmUgU0FORS1VU0VSUz8gKG5vdCAnSEFIQS1KL0shKSkKCihkZWZpbmUgKHd0Zi13b3J0 aHkgeCkKICAob3IgKHByb2NlZHVyZT8geCkKICAgICAgKHByb21pc2U/IHgpCiAgICAgICh2ZWN0 b3I/IHgpCiAgICAgIChhcnJheT8geCkKICAgICAgOzsgZXRjCiAgICAgICkpCgooZGVmaW5lIChh cy1zdHJpbmctbWF5YmUgeCkKICAoY29uZCAoKG9yIChub3QgeCkKICAgICAgICAgICAgICh1bnNw ZWNpZmllZD8geCkKICAgICAgICAgICAgIChudWxsPyB4KQogICAgICAgICAgICAgKGFuZCAoc3Ry aW5nPyB4KQogICAgICAgICAgICAgICAgICAoc3RyaW5nLW51bGw/IHgpKSkKICAgICAgICAgI2Yp CiAgICAgICAgKChlcT8geCAjdCkgInQiKQogICAgICAgICgoc3RyaW5nPyB4KSAoaWYgU0FORS1V U0VSUz8KICAgICAgICAgICAgICAgICAgICAgICAgIHgKICAgICAgICAgICAgICAgICAgICAgICAg IChzcGFjZS1zZXAgeCkpKQogICAgICAgICgod3RmLXdvcnRoeSB4KSAoY29uZCAoU0FORS1VU0VS Uz8KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICh3YXJuICJXVEY6IiB4KQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgI2YpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IChlbHNlCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoZXJyb3IgIldURjoiIHgpKSkp CiAgICAgICAgKGVsc2UgKG9iamVjdC0+c3RyaW5nIHgpKSkpCgooZGVmaW5lIChzcGFjZS1zZXAg eCkKICAobGV0ICgoYWNjICcoKSkpCiAgICAoZGVmaW5lICh3YWxrIHgpCiAgICAgIChjb25kICgo cGFpcj8geCkKICAgICAgICAgICAgICh3YWxrIChjYXIgeCkpCiAgICAgICAgICAgICAod2FsayAo Y2RyIHgpKSkKICAgICAgICAgICAgKChhcy1zdHJpbmctbWF5YmUgeCkKICAgICAgICAgICAgID0+ IChsYW1iZGEgKHMpCiAgICAgICAgICAgICAgICAgIChzZXQhIGFjYyAoY29ucyBzIGFjYykpKSkp KQogICAgKHdhbGsgeCkKICAgIChzdHJpbmctam9pbiAocmV2ZXJzZSEgYWNjKSkpKQo= --=-=-=--