contrapunctus
/
mkly
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

README - described new sub-project target idea

This commit is contained in:
contrapunctus 2020-12-02 02:24:57 +05:30
parent 57ebdf732f
commit 2234729c0e
1 changed files with 18 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
README.org
View File

@ -19,6 +19,21 @@ Guile must be available at =/usr/bin/guile=
4. In your project root, run -
: ./mkly
** Invocation
mkly can be run without arguments -
: mkly
Doing so will execute the /action/ in the first (top-most) defined /rule/.
You can pass one or more /targets/ -
: mkly <target>*
Each target will be checked against the defined patterns, and the actions for all matching patterns will be run.
If a subdirectory is supplied, mkly will descend to it for all following targets (until another subdirectory on the command line is encountered) -
: mkly main foo/ dev bar/ main dev
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/".
If there is a mkly-rules.scm in the subdirectory, the targets following the subdirectory will be matched against patterns defined in that file. If there isn't such a file, the patterns from the directory mkly was called in will be used instead.
** The defaults
The default rules make certain assumptions about your project structure -
1. You have a main.ly in the project root containing all musical parts
@ -52,14 +67,15 @@ Rules are returned as a list by the procedure =rules=, defined in the project-sp
- 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.
8. [X] Targets containing other targets.
+ 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 construct the path to the script (using getcwd)
+ 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)
9. [-] Shell globs, both in targets and in actions.
* [X] Document shell-path as a user variable
* [ ] Use shell-path to run commands
10. [-] Sub-project operations
1. [X] Specify targets for sub*-project(s), instead of project in 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!
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. (use globs)