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

[Jörg F . Wittenberger]

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"
   target.

   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
http://askemos.org/A64fd47967c1b1100720ba89b51d2dae0



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

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


/Jerry




...........