Nathan Sidwell <nat...@acm.org> 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 compiler? > 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 functionality. 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.
