Hi Steve,
On Sun, Jan 13, 2019 at 11:28:00PM +0100, Thomas Koenig wrote:
the attached patch adds a -fwrite-module-files options, but the main
point is that it adds its opposite, -fno-write-module-files.
This has advantages in parallel compiling, as it is quite fast to
generate a module file with -fsyntax-only, and a subsequent
compilation with -fno-write-module-files will not overwrite this.
A worker checks out a copy of the code from the community
source repository. At the same time, her coworker checks
the same revision. She then works for a week on the project
and adds new public routines to a module. She checks her
work into the master repositrory. Meanwhile, her coworker
used -fsyntax-only to generate module files, and then added
the -fno-write-module-files option in his local Makefiles.
He now syncs his local sources with the repository. If
-fno-write-module-files prevents writing a module file,
how do the new interfaces magically appear. There isn't
a magic bullet for proper dependencies with parallel
compiling.
I agree there is a possibility for misuse, which is why I put
"When code has been changed and
@option{-fno-write-module-files} is used, it is possible to generate
inconsistent module files, which will lead to hard-to-find bugs. Use
with care." into the documentation.
Still, if changing basic compilation methology is not communicated
among team members who may be affected, I whould say that this
is a severe case of project management failure, not a compiler
problem, and I do see a legitimate use case for this.
Regards
Thomas
