Here, target "main" will be run in the project root, target "dev" will be run in the subdirectory "foo/", and target "main" and "dev" will be run in subdirectory "bar/".
Rules are returned as a list by the procedure =rules=. This procedure can be redefined by loading your own Scheme file, by running =mkly= with the =--load=/ =-l= command line option.
Some default variables are defined for use in defining rules -
1. project-root - the project root directory
2. project-name - by default, the basename of the parent directory
3. shell-path - path to the shell you want to use for running your commands
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.
+ I've tried calling the script itself with the required targets - not sure if that actually works. Especially considering that #7 - multiple targets in one command - isn't implemented yet.
+ If =mkly= is not in the user's $PATH and is invoked as =./mkly=, the shell won't be able to find it if it calls itself. We can try constructing the path to the script (using =getcwd= - if =(first (command-line))= is "./mkly", it's in the current working directory)
* The current way is somewhat inelegant, though - you either modify all rules to also work in sub-projects, or you make new rules for sub-projects...why can't the same rule work for both? What if we could specify a subdirectory, followed by the usual targets, resulting in us =cd= ing into that directory and running the usual targets? Same rules working in both situations!
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
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
* one possible way - all actions are Scheme expressions - for shell commands, create a ($ ...) form (with =$= doing what =run= does now) which is =eval=-uated if it matches a target. (see branch "$-syntax")
6. [ ] Replace regexp patterns with glob patterns?
* more consistent (since targets and actions use globs too), but possibly less powerful.
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]].
* [ ] Default rule (no pattern provided) and =else= seem to conflict - do we want to do different things when there's no pattern provided and when a provided pattern does not match, or the same thing?
* [ ] Meta-targets - if the command does not match another rule, run as shell command; otherwise treat as list of targets
3. [ ] chdir to project root before descending into subdir