Personal action plan for Makeshift

    - Why proper path `building/Makeshift` as opposed to `Makeshift`?
        ∵ Makeshift is building code that builders elsewhere depend on.
            : see `^*‘builder’.vs\..‘building’$`

    builders
        / Properly ‘software builders’.
      \ - A builder is coded all in one file.
      \     - A default copy of the builder is included in the release package.
      \     - The builder itself warns if it needs to be updated owing to change in the default copy.
      \         / Viz. after a new release of the Breccia Web imager has been installed.
      \         - Only a programmer will ever see this, or have to act on it.
      \         - It is updated manually by reference to a public diff.
      \             / E.g. via a URL into a Web copy of the release repository, e.g. on Git Hub.
      \             / Later maybe also as Gentoo users do, by a tool-assisted merger.
      \ - To personalize the builder, I will build from a private branch of the project.
      \     - While I code in the master branch, I build in my private branch.
      \     - My private branch alone has my personalized copy of the builder.
      \     - Building initially entails merging any changes from the master branch and, if necessary,
      \       restarting the builder.
        - The function of software builders is personalized as follows.
            - They use the general path mechanism of the OS.
                / E.g. to locate the JDK.
            - They use conventional locations.
                / E.g. `/tmp/` in the case of the output directory,
                  namely `/tmp/building.Makeshift/<project-proper-path>`.
            - They use relative file references.
                / E.g. to locate other projects which are dependencies.
            - They take parameters.
                - Via the shell.
                - Via environment variable `BUILD_PARAMETERS`.
        - They put intermediate and end results under `/tmp/building.Makeshift/<project-proper-path>`.
        - Software builders use:
            • `jpackage`
                : see https://openjdk.java.net/jeps/343
                + Would it be useful, given builder and launcher?
    ‘builder’ vs. ‘building’
        - Term (and project subdirectory) ‘builder’ I use to refer to a project’s proper builder
          together with the building code (internal and external) it depends on and entails.
        - Term (and directory) ‘building’ I apply to building code that builders elsewhere may depend on.
        / E.g. the Java programming project’s proper builder I might store in `Java/builder/`,
          while in `Java/building/` I house a separate project of Java-specific building code.
    target naming
        - Characters ‘-’ and ‘_’ are equivalent in user-given target names.
            ∵ The user description for targets is in source code that necessarily uses ‘_’,
              while ‘-’ is more convenient for users to type in the shell.
        - Targets are defined in the source code as enumeration constants each having a lower-case name.
            ∵ Lower case, while atypical, is more convenient for users to type in the shell.
    testing
        >+ clean && build building/Makeshift/example/top/ builder custom
        >+ clean && build building/Makeshift/example/top/ builder
        >+ clean && build building/Makeshift/example/top/ custom
        >+ clean && build building/Makeshift/example/mixed_top/ builder custom class_files
        >+ clean && build building/Makeshift/example/mixed_top/ builder
        >+ clean && build building/Makeshift/example/mixed_top/ custom
        >+ clean && build building/Makeshift/example/mixed_top/ class_files
        >+ clean && build building/Makeshift/example/sub/ builder custom class_files
        >+ clean && build building/Makeshift/example/sub/ builder
        >+ clean && build building/Makeshift/example/sub/ class_files
        >+ clean && build building/Makeshift/example/sub/ custom