[Top][All Lists]

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

Re: [Chicken-users] A Scheme based make - soliciting you comments

From: Jörg F . Wittenberger
Subject: Re: [Chicken-users] A Scheme based make - soliciting you comments
Date: 12 Jun 2013 23:15:36 +0200

Hi Moritz,

On Jun 12 2013, Moritz Heidkamp wrote:

Hi Jerry,

Jörg F. Wittenberger <address@hidden> writes:
these days I ran (again as every once in a while) a case which made me
longing for a make(1) in Scheme. Gave the make egg a try and… decided
I'd need something else. Something powerful enough to make it easier
to maintain Chickens build and similar complex things.

I know the feeling! And I have started a project in that direction, as
well. It's been on a detour due to some yaks on the road for a bit now
but I have hopes to find time to hack on the actual thing again
soon. Also I have some yak fur coats to spare if anyone is interested.

Might be interesting!

So far I ended up with something working. I'm not yet sure that it's worth the effort to document/release it, so please tell me if you like it.

I've looked at it and have a question: It looks like you chose to build
a separate language (or preprocessor) on top of Scheme. Is that
assessment correct?

50/50.  That is: yes, since there is no half-pregnant.

ssx (in it's primary mode) works quite like make(1): feed it a build
description, which is interprets and executes.

Can you explain why you chose to do so?

There are exactly two primitives, which I did not (yet) implement
in pure Scheme.  The reason: I'd rather love to discuss the pros and cons
before.  For the time being I wanted those to be a straight error if
fed to a Scheme interpreter - makes it much easier to spot them once
it became clear how they should look alike.

Those are:

1.) The way to get build parameters from the invocation.
   Meanwhile there is little need left to keep this as a special syntax.
   (Except maybe for just the reason that they are so easy spotted.)

   Currently written as
   #(param: <string-or-symbol-as-identifier> <default>)
   where <default> is optional.  And I used additional vector elements
   for a short docstring tentatively to be extracted by some "help"

   Could be written like:

    (define internal-name (make-parameter "ENVSTRING" default))

2.) Conditional Code Inclusion

   Basically an "alternative" to cond-expand, but:

   * must take into account those parameters from above.
   * should allow rather arbitrary Scheme expressions as predicates,
     not just feature identifiers as cond-expand does.
     Rationale: be practical.  cond-expand is good for Scheme, but
     is it good for a make?

   I choose to not use s-expressions for this construct and I doubt
   that doing so would be a good idea.  Those conditional are typically
   introduced late in the project.  E.g., when adding a port to another
   platform.  Often they are temporary until a better solution is found.
   You don't want to re-indent all your code in that case.  It ends up
   *all* in the diff.

   Therefore I wanted a syntax here, which would produce single line diffs.

   (((It's also a bit motivated by my lengthy and good experience with
   using Scheme embedded in XML/XSLT: for the complex code, which fits
   on a screen I use Scheme.  But larger sections go into XML/XSLT.
   Advantage: You get a much better idea, were the hell the missing
   parenthesis should go.  Plus: you can always compile the whole
   thing into s-expressions.)))

In my
project I aim for a make(1) replacement *in* Scheme (kind of like the
make egg, only more flexible) which seems sensible to me, given its
syntactic extensibility.

Let me mention another feature I deemed useful, but I'm little unsure
how useful it would turn out to be:  It's possible to track files
as either source or result and will not easily (currently not at all)
overwrite a source file.  Side effect: there's a list of all sources
readily to create a manifest file and distribution with no need to
maintain those list manually.  Both features for the lazy programmer,
who has something better to do than re-build things over and over until
all files are included.  Would you consider that worthwhile?

Otherwise I'm now able to give a little update on the project state:

I added a secondary operation mode: instead of interpreting the build
description right away, it will write it into a chicken module.
All "make-driver" code is included; only dependencies on core chicken.

In this context we come closer to the "why" of your question.  Instead
of core chicken, this could even be a super-simple Scheme like the siod
as it was 20 years ago, with no macro expander etc.  Or maybe even
a shell script or you name it.  Something which always works; at least
for the initial build.

Compiling the resulting module makes it easy to spot miss-spelled variables.
A big win over normal make, which would simply expand them to nothing.

This mode was very helpful when converting the Chicken build.
Just today I compiled this result module with csc -static-libs then
de-installed chicken from my system expanded the tarball from "make dist"
and ran the static-linked thingy.  This did the build (so far only
the Makefile.linux and the *.make files where "converted"; hence only
Linux builds by now.)  Here is the code

… and this takes me to the question: are you Chickeners interested
in dropping the GNU-make dependency in favor of a pure Chicken based

If yes: so far the "converted" build description mirrors 1:1 the
build code from Chicken.  All identifiers retained, same sequence
of declarations, everything.  Whoever knows this code should feel
home right away. --  But: why should we go to the trouble anymore?
Quite a huge part of it is dealing with WINDOWS_SHELL and external
programs just to copy a few files around.  I'd rather replace all
this with pieces from the units posix and files.  This should result
in even less code to maintain.

Best Regards



reply via email to

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