From: Paul Smith <psmith@gnu.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guile-user@gnu.org
Subject: Re: Guile support in GNU make
Date: Mon, 16 Jan 2012 09:07:58 -0500 [thread overview]
Message-ID: <1326722878.3482.334.camel@homebase> (raw)
In-Reply-To: <8762gchbf8.fsf@gnu.org>
On Sun, 2012-01-15 at 23:02 +0100, Ludovic Courts wrote:
> And thanks for the great news! :-)
I promoted the feature to GNU make CVS (I know, still CVS!!) on
Savannah. I hope to generate a test dist file sometime this week. I'll
email when it's available if people want to take a look.
> Paul Smith <psmith@gnu.org> skribis:
> >> - The ‘#t => t’ distinguishes the symbol t from others, which feels wrong.
> >> I suggest #t => ""; #f => error.
> >
> > Hm. The problem with this is that we can't easily use Guile booleans in
> > GNU make. For example, the syntax for make's $(if ...) function is:
> >
> > $(if <condition>,<then>[,<else>])
> >
> > The <condition> is expanded as a makefile expression and if it's empty
> > it's considered false. If it's non-empty it's considered true.
>
> Would it be possible for Make to delay the conversion of SCMs to
> strings, and in turn to differentiate between conditions as strings, and
> conditions that are SCMs?
I don't think this is possible. Make has no "data types" at all. It
just manipulates strings--every operation in make is a string operation,
and the "results" of operations are just constructing new string buffers
by doing string manipulations, then passing that string to the next
function (or whatever).
There's just no facility anywhere internal to make to store or
manipulate a non-string item.
I suppose one option would be to have #f translate to the string "#f"
and change the definition in make of "false" to be "either the empty
string OR the string #f". Since "#" is a comment character in make it's
highly unlikely (although not impossible) someone would have that as a
valid value. However, this would be a lot of effort (finding all the
places in make that use the empty string as "false" and modifying them).
And I'm not sure it wouldn't cause other issues. I think, all in all,
it's better to leave it as-is unless someone can point out a real
problem with it (besides a general unpleasant aftertaste).
--
-------------------------------------------------------------------------------
Paul D. Smith <psmith@gnu.org> Find some GNU make tips at:
http://www.gnu.org http://make.mad-scientist.net
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
next prev parent reply other threads:[~2012-01-16 14:07 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-14 19:55 Guile support in GNU make Paul Smith
2012-01-15 8:51 ` Thien-Thi Nguyen
2012-01-15 12:33 ` Thien-Thi Nguyen
2012-01-15 16:12 ` Paul Smith
2012-01-15 20:11 ` Thien-Thi Nguyen
2012-01-15 20:49 ` Paul Smith
2012-01-15 22:02 ` Ludovic Courtès
2012-01-16 14:07 ` Paul Smith [this message]
2012-01-17 22:42 ` Ludovic Courtès
2012-01-17 23:26 ` Paul Smith
2012-01-19 20:42 ` Ludovic Courtès
2012-01-19 22:14 ` Ludovic Courtès
[not found] <1316557011.28907.237.camel@homebase>
[not found] ` <1326572016.3482.144.camel@homebase>
[not found] ` <20120122182923.GB3460@mini.zxlink>
2012-01-22 21:56 ` Paul Smith
2012-01-23 6:01 ` Thien-Thi Nguyen
2012-01-23 6:08 ` Thien-Thi Nguyen
2012-01-29 20:05 ` Paul Smith
2012-01-31 19:17 ` Kirill Smelkov
2012-01-31 21:32 ` Paul Smith
2012-01-25 23:45 ` Ludovic Courtès
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://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1326722878.3482.334.camel@homebase \
--to=psmith@gnu.org \
--cc=guile-user@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.
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).