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 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
...........
_______________________________________________
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
