unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Paul Smith <psmith@gnu.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guile-user@gnu.org
Subject: Embedding vs. Extending (was: Re: Using guile as an extension language for GNU  make)
Date: Sun, 18 Sep 2011 13:21:08 -0400	[thread overview]
Message-ID: <1316366468.28907.138.camel@homebase> (raw)
In-Reply-To: <87pqiyaw5w.fsf@gnu.org>

On Sun, 2011-09-18 at 14:10 +0200, Ludovic Courts wrote:
> Ideally, when Guile support is enabled, GNU make would be turned into
> a Guile extension (a shared library and its companion Scheme module
> that loads it with ‘load-extension’) that would expose make’s
> functionality.

I'm not sure I'm interested in going to that extreme.  GNU make has one
overarching, guiding concept: it's a critical component of a GNU-based
POSIX environment.  All POSIX-standard makefiles must work in GNU make,
and there are hundreds of thousands of already-existing makefiles, both
for POSIX and GNU versions of make.  Obviously asking people to start
writing makefiles in Scheme would not be appropriate.

A technically acceptable option would be to build GNU make in two forms:
first a standalone application that worked as now, and second a
"library" that could be linked as a Guile extension.

However, from what I've read of Guile that would be an immense amount of
work: GNU make was created over 20 years ago and has a lot of
not-completely-clean features and implementation details which rely on
it being a stand-alone program.  There's massive amounts of global
memory usage, not even a nod to threading capabilities or locking, and
features like automatically re-exec'ing itself in some situations.

Finally, while it's a cool idea I'm not sure there's a compelling need
for this.  Have lots of people wanted to be able to define make-type
rules and invoke make-like algorithms in Guile programs?  Coming from
the GNU make side, I've never heard of such a request.  Of course
sometimes the usages aren't clear before the capability exists;
nevertheless there are so many things to do to GNU make proper that I
can't justify the effort this would take, for the apparent return
involved.  If someone else were interested in it I'd be happy to work
with them on cleanups to the GNU make codebase that would enable this,
as long as they were generally appropriate.


My main purpose is to add some kind of scripting capability to GNU make
to augment the current functions capability.  So many people want me to
add new functions to GNU make, and they're very useful functions, but
I'm not interested in creating yet another complete scripting language.
I'd rather choose an existing language and allow GNU make makefiles to
take advantage of it.  Guile seems like a natural choice for many
reasons.

-- 
-------------------------------------------------------------------------------
 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




  reply	other threads:[~2011-09-18 17:21 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-18  0:10 Using guile as an extension language for GNU make Paul Smith
2011-09-18 12:10 ` Ludovic Courtès
2011-09-18 17:21   ` Paul Smith [this message]
2011-09-18 21:48     ` Embedding vs. Extending Ludovic Courtès
2011-09-18 17:42   ` Using guile as an extension language for GNU make Paul Smith
2011-09-18 21:28     ` Ludovic Courtès
2011-09-18 15:30 ` Thien-Thi Nguyen
2011-09-18 19:28   ` Paul Smith
2011-09-19  0:28     ` Thien-Thi Nguyen
2011-09-19 15:14       ` Paul Smith
2011-09-19 19:41         ` Hans Aberg
2011-09-19 21:56           ` Paul Smith
2011-09-19 22:35             ` Hans Aberg
2011-09-19 23:00             ` Hans Aberg
2011-09-21  2:42             ` Mark H Weaver
2011-09-21  8:24               ` Hans Aberg
2011-09-20 16:17         ` Thien-Thi Nguyen
2011-09-20 17:31           ` Paul Smith
2011-09-20 19:02             ` Paul Smith
2011-09-21  0:48               ` Thien-Thi Nguyen
2011-09-20 20:39             ` Thien-Thi Nguyen

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=1316366468.28907.138.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).