Hi Moritz,
On Jun 12 2013, Moritz Heidkamp wrote:
Hi Jerry,
Jörg F. Wittenberger joerg.wittenber...@softeyes.net 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
