[00/32] C++ 20 Modules
Fri Nov 6 14:26:02 GMT 2020
Nathan Sidwell <email@example.com> writes:
> The repo is providing a mechanism by which two processes can synchronize
> on a fixed location in the file system that is not /. You need such a
> capability as the file system is the bulk transfer mechanism.
> The alternatives are to always use absolute paths, or require the two
> ends of the communication to have the same working directory [...]
Isn't the latter pretty much the norm for a build system that spawns
> The location of the repo is entirely under the mapper-server's control.
> Set it to / if you want.
Except that now all my relative paths are relative to / and not CWD.
I find the current semantics heavily skewed towards the mapper operating
outside the build system (like the builtin mapper) while I expect most
non-toy/legacy build systems that wish to support C++ modules to have
an integrated mapper (build2 certainly does it this way). I think there
should at least be a way for the mapper to opt out of this repository
Also, you mentioning synchronization reminded me of this part from
Invoking GCC/C++ Modules:
> When creating an output CMI any missing directory components are
> created in a manner that is safe for concurrent builds creating
> multiple, different, CMIs within a common subdirectory tree.
> CMI contents are written to a temporary file, which is then atomically
> renamed. Observers will either see old contents (if there is an
> existing file), or complete new contents. They will not observe the CMI
> during its creation.
This works atomically on POSIX but not on Windows. Also, from experience,
on Windows creating a temporary file and then renaming it often causes
more problems than creating it in the final destination from the outset.
That's because on Windows you cannot (re)move a file that is open by
another process. And there are various processes on Windows (anti-virus/
malware, indexers, IDEs, etc) that routinely scan the filesystem.
More information about the Gcc-patches