<contrapunctus> I have files whose output names don't necessarily correspond to the input file names. (e.g. main.ly -> output/songname.pdf) Also, entering the output file name to specify which file to compile isn't convenient.
[2016-06-03T20:10:26+0530]
<contrapunctus> so I can have the pattern rule and correct dependency-modified checking (although that's completely useless for Lilypond, as here the smallest of changes in any source file will always trigger the whole output file to be recompiled), and do without good names; or I can have the good names and always run make with -B :\
[2016-06-03T20:16:11+0530]
<contrapunctus> I have half a mind to just write a friggin shell script.
<contrapunctus> and they say irregular/complex/rich syntax is not an issue - http://mywiki.wooledge.org/BashGuide/CommandsAndArguments
[2016-06-03T20:35:50+0530]
<contrapunctus> I even took the simple evaluation of lisps for granted until I came to makefiles...I didn't read all that stuff about how makefiles are evaluated, but the fact that it takes up a section instead of a friggin' paragraph oughta tell one something.
[2016-06-03T20:36:39+0530]
<contrapunctus> I suppose this is the time a programmer goes out for a stiff drink
[2016-06-03T20:37:35+0530]
<contrapunctus> "<contrapunctus> I remember fuming over having to learn ASDF when learning CL, but even that was easier than this :\" - #learnprogramming
<contrapunctus> so I have some trouble with the bash script I make
[2016-06-04T09:08:11+0530]
<contrapunctus> (mostly because I tried to avoid arg parsing)
[2016-06-04T09:08:36+0530]
<contrapunctus> someone in #learnprogramming says "personally, i would do this in python or ruby or lua or something, where you have a ton of nice libraries to help with that stuff. for me personally, bash always seems like more trouble than its worth"
[2016-06-04T09:09:04+0530]
<contrapunctus> I express my desire to do it in Scheme or Lisp, but I 'can't count on those being there on every system'
[2016-06-04T09:09:20+0530]
<contrapunctus> other person - 'isn't lilypond written in scheme?'
[2016-06-04T09:09:32+0530]
<contrapunctus> lightbulb moment - I could just write the script in guile :D
1. [X] Make it declarative - define options and their effect, and the structure of the command, separately from the code that makes it happen.
2. [X] Use regexps to define target names and how the output file name(s) derive from them.
3. [X] Name files differently if PAC is on - The upside of this is, you don't accidentally send someone the point-and-click-enabled version of the file.
The downside is, it's easy to have file-pacON.pdf open during editing, while the script is actually compiling to file.pdf (or vice-versa) [fn:1], and wonder why your score isn't updating.
4. [X] Create output directory if it doesn't exist!
5. [X] Remove duplicate layer of CLI options - currently there's a needless extra layer of CLI options for options which already exist. Should make code simpler, UI familiar.
+ But the Lilypond CLI is ugly - what's better, "pac=off", or "-dno-point-and-click"? :\
- After the revamp, the script doesn't (yet) aim to want to support options like this; the idea is that the user specifies a /situation/ as a target, and all options relevant to that situation are passed (as specified in the rules by the user). It's a "maybe" to-do.
6. [ ] Tab completion of specified target names
7. [ ] Multiple targets in one command e.g. to compile both the main score and the parts in one command.
8. [ ] Targets containing other targets.
+ I've tried calling the script itself with the required targets - not sure if that actually works. Especially considering that #8 - multiple targets in one command - isn't implemented yet.
9. [ ] Shell globs, both in targets and in actions.
10. [ ] Sub-project operations
1. Specify targets for sub*-project(s), instead of project in current working directory.
2. Use sub-project-specific mkly-rules.scm if present, else use project-root mkly-rules.scm
3. I want to compile a particular target in every subproject.
(Old) implementation notes
1. Maybe...if the input file in a target entry is just a "/" (or maybe "->"?), the target name will be understood as being the target to run in either
1. all subdirectories directly below the directory containing the current build.scm (in this case, it is an error if any of these subdirectories do not contain a build.scm)
2. all subdirectories in which a build.scm can be found, directly below the directory containg the current build.scm
[fn:1] These are likely to happen if you have a compile-with-last-command-on-save setup, like in my Emacs.
** Maybe [0%]
1. [ ] Allow users to define (command-line) options and their effect.
2. [ ] VCS branch integration - check what branch you're on. If it's branch X (e.g. "main"), do nothing. If it's something else, add the name to the output file.
+ Or to the output directory name, e.g. files from the main branch go to "output/", files from branch "foo" go to "output-foo/", etc.
3. [ ] Default rules for orchestral projects - for target part-<instrument>.ly, compile <instrument class>/<instrument>.ly
This is a [[http://lists.gnu.org/archive/html/guile-user/2015-12/msg00054.html][Guile]] [[https://debbugs.gnu.org/cgi/bugreport.cgi?bug%3D22229][bug]].
