Re: Cleanup initialization of configure process (issue 549350043 by address@hidden)

[nine . fierce . ballads]

Let me try to recount all the factors that did or do contribute to my
liking a read-only source directory.  This is mainly to help me decide
whether to concede this feature, not to elicit any response from you.

Unstable virtualization.  Linux in VirtualBox (which I no longer use) on
macOS did not handle sleeping and waking gracefully.  The time of day in
the guest would get out of sync.  From time to time, the kernel would
panic.  In those days, I was keeping my LilyPond work in a virtual disk
image (VDI), but I didn't want the host to back up the whole multi-GB
VDI file whenever any part of it changed, and I didn't want to jump
through the additional hoops to get the source out of the VDI for
backup.  Instability with no backup gave me the heebie-jeebies.  Now,
with Docker, I store my work on the host, where it is included in
automatic backups.  Docker has been much more stable than VirtualBox
was, though at the time I switched, I carried over some concern that it
might foul up something in my host filesystem if I gave it write access.

Debugging.  When you're debugging a build script, even if you mess
something up, there is no way it can defile or destroy your source files
when they are mounted read-only.  Sure, source control could be used to
recover, but who wants to commit before every test run just in case a
disaster occurs?  A similar case is when you've turned your build
directory into a shambles.  You can simply remove it and be sure that
you've gotten everything; you don't have to sift the source directory
for generated files that might affect your next build.

Storage quotas.  I keep my build directory on a separate partition so
that an unexpected increase in storage requirements will cause the build
to fail rather than infringe on the rest of my space.  I don't want to
keep my source on that limited partition, but I still don't want
programs running in the container to be able to use as much space as
they please in the source directory.

Performance.  Docker access to macOS host files is slow.  (I recall that
`make check` takes 3-4 times as long when the build directory is stored
on the host than when the build directory is in a "Docker volume.")
This would a good reason NOT to store your source on the host, but if
you want to store it on the host for other reasons (e.g. simplified
backup), this IS a good reason to limit the container's access to
reading, because Docker offers the option to cache the host's version of
the files.  I don't recall measuring the impact of caching the source
directory; I've been taking the documentation at its word.

https://codereview.appspot.com/549350043/