Re: [Chicken-users] A Scheme based make - soliciting you comments
sorry, I'Ve been lying. Accidental :-/ On Jun 12 2013, Jörg F. Wittenberger wrote: 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! It the source anywhere? 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? ... 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.) Here I forgot the reason, why I decided that I don't know how I could write this simply in Scheme: You want to be able to fine-control how to overwrite these build parameters without having to write them into a file, but also allow this as one possible alternative. BTW: just feed another file after the standard build description will not work easily. While we could overwrite definitions there, it's too late since prior values where defined with the defaults effective instead. The only way I'd see would be to feed in three files: the defaults followed by the overwrites then the build rules. Just too impractical and error prone. Best idea so far: the *first* definition wins. Example: #(param: PREFIX /usr/local) == look for PREFIX in the environment, use this if found, else /usr/local Example2: use with two files; put the local config before the standard file one: config.mk.scm #(param: PREFIX /home/me/build/test ) == look for PREFIX, use /home/me/build/test if not set file two: standard.mk.scm #(param: PREFIX /usr/local) ;; as before == second definition for PREFIX, find it already defined ignore this one. In a related note: I do actually: * contemplate to allow a choice of languages instead of Scheme for the actions and all * once that's done, implement a *restricted* version of Scheme, which would *not* allow set! and other side effects and accept no overwrites for definitions + show that this is still easy enough to use for the purpose + demo that it results in much more readable and clearer build descriptions + assuming the last two + didn't fail: recommend this one only 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. BTW: This is also hard in plain Scheme: there can be `define`s in alternate conditional sections. Either as declarations of the same parameter with a different default or as normal `(define var val)` Those you want to be visible at top level; don't you? (when test (define PREFIX /home/me/testdir) )??? Wrong scope! Best Regards /Jerry ... ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] A Scheme based make - soliciting you comments
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. 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? Can you explain why you chose to do so? 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. Moritz ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] A Scheme based make - soliciting you comments
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
