mkly/README.org

* History
** Misadventures with make
*** ##emacs.de
#+BEGIN_EXAMPLE
[2016-06-02T21:38:49+0530]
<contrapunctus> Make sagt, "<Datei> ist bereits aktuell", aber ich habe sie gleich geändert :\
#+END_EXAMPLE

*** PM
#+BEGIN_EXAMPLE
[2016-06-03T20:03:45+0530]
<contrapunctus> hmf :\
[2016-06-03T20:07:02+0530]
<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.
#+END_EXAMPLE

** Bumbling with bash
#+BEGIN_EXAMPLE
[2016-06-03T20:33:02+0530]
<contrapunctus> and now...time to learn bash
[...]
[2016-06-03T20:34:53+0530]
<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
[2016-06-03T20:37:58+0530]
<wasamasa> :D
[2016-06-03T20:38:11+0530]
<wasamasa> ASDF is after all, designed
#+END_EXAMPLE

** Simply stellar Scheme!
#+BEGIN_EXAMPLE
[2016-06-04T09:08:01+0530]
<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
[2016-06-04T09:09:40+0530]
<contrapunctus> (= dependency of Lilypond)
[2016-06-04T22:27:05+0530]
<contrapunctus> also, schnell zusammengehackt (lol) - http://ix.io/OJA/scm
[2016-06-04T22:30:35+0530]
<contrapunctus> ich habe die getopts-long Bibliothek benutzt können, aber...hm, ich kann mich an den Grund nicht mehr erinnern o_O
[2016-06-04T22:33:04+0530]
<contrapunctus> (vielleicht sehen die *ohrschützer*mäßige Variablen nicht schön und Common-Lisp-artig aus?)
[2016-06-04T22:34:16+0530]
<wasamasa> mein aktueller gesichtsausdruck: http://brause.cc/srs/neeein.jpg
[2016-06-04T22:51:02+0530]
<contrapunctus> was o_O
[2016-06-04T22:51:25+0530]
<contrapunctus> so schrecklich ist es?
[2016-06-04T22:53:06+0530]
<contrapunctus> was soll ich darin verbessern?
[2016-06-04T23:11:31+0530]
<wasamasa> dieses deutsch ist einfach fürchterlich
#+END_EXAMPLE

* TODO
1. Make it declarative - define options and their effect, and the structure of the command, separately from the code that makes it happen.
2. Use regexps to define target names and how the output file name(s) derive from them.
3. Also, add support for part-<instrument>.ly -> <project-name>-<instrument>.pdf files.

   Hypothetical config in that style -

   #+BEGIN_SRC scheme
     (options
      (pac ("off" "-dno-point-and-click")
           (_ ""))
      (size ("a4" "-a4")
            (_ "")))

     ;; TARGETS defines build targets for the project, in the form
     ;;   (targets ENTRY*)
     ;; Each ENTRY is in the form -
     ;;   (TARGET-NAME INPUT-FILE OUTPUT-FILE)
     ;; TARGET-NAME is the target name, specified by the user at the
     ;; command line while calling the script.
     ;; INPUT-FILE is the stem name of the file to be compiled.
     ;; OUTPUT-FILE is the stem name of the file to be passed as output
     ;; file name to the compiler command

     ;; Inside a target entry, the keyword 'target' is automatically bound
     ;; to the target name - here, "main". The first entry given here means
     ;; - "specifying 'main' as target (on the CLI) will compile a file
     ;; called 'main' (the extension is added in the command stage) and
     ;; will have <project-name> as output stem."
     (targets
      ("main" target project-name)
      ;; for target "band", compile "band", output "<project-name>-band"
      ("band" target (string-append project-name target))
      ("tags" (non-ly "etags -l none -r '/^[a-zA-Z]*\ *=/' *ly"))
      ("clean" (non-ly "rm -r output/"))
      ;; for target "foo", compile "part-foo", output "<project-name>-foo"
      (_ (string-append "part-" target)
         (string-append project-name "-" target)))

     ;; input-file and output-file are taken from the first and second args
     ;; of the target as defined in TARGETS
     (command "lilypond" pac "-o output/" output-file size " " input-file size ".ly")
   #+END_SRC

   Alternative way?
   1. Instead regexps. If the supplied target matches a regexp for a

4. Tab completion
5. Recursive operations. Sometimes I have large projects with subprojects (and even sub-subprojects) in them. Usually, I want to compile a particular target in every subproject.
   - 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
6. Create output directory if it doesn't exist!
7. Targets containing other targets.

   It would also be useful to compile the part-<instrument>.ly file if I'm editing an <instrument-class>/<instrument>.ly file - useful when working with orchestral files and wanting to put the generated MIDI in qtractor (importing a single track is easier than importing a multi-track MIDI just because you changed music on one track). That's more of an Emacs-side thing, though.

   ...hell, one could define all kinds of rules - "when I'm working with such-and-such files, compile such-and-such targets."
8. Multiple targets in one command e.g. to compile both the main score and the parts in one command.

** VCS branch integration (2018-11-22T19:43:42+0530)
Check what branch you're on. If it's "master", do nothing. If it's something else, add the name to the output file.
** (2018-11-15T00:44:46+0530)
Currently there's a needless extra layer of arguments for arguments which already exist. Just accept compilation target(s) and pass all of the rest to lilypond(1). Should make code simpler, UI familiar.
- But the Lilypond CLI is ugly - what's better, "pac=off", or "-dno-point-and-click"? :\
** lack of tab completion sucks (2016-09-29T02:18:01+0530)
I can't even use tab completion from Emacs because the target name has to be "part-<instrument>", not "part-instrument.ly" (so I have to keep deleting the .ly bit)
** naming files differently if PAC is on (2018-08-30T03:50:37+0530)
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) [1], and wonder why your score isn't updating.

[1] These are likely to happen if you have a compile-with-last-command-on-save setup, like in my Emacs.
* Bugs
1. Barfs when placed in and run from directories with a path containing non-ASCII characters.

   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]].